Re: [Squeak-VMdev] fullDisplay, ioForceDisplay etc

[Tim R. <ti...@su...>]

In message <ED1...@in...>
          Ian Piumarta <ian...@in...> wrote:


> fullDisplayUpdate() calls ioShowDisplay() for the entire Display (or 
> whatever surface, yada yada) area.
That one is pretty reasonable though the commenting could be more
helpful as to the actual users. It doesn't refer to deferDisplayUpdates
within any of the slang code.
> 
> ioShowDisplay() tells the VM that the Display has changed (and where).  
> (E.g., the Unix/X11 code grabs a PixMap out of the Display object and 
> paints it into the X11 window, but network/server latencies don't 
> guarantee an immediate effect on the physical screen.  Other VMs might 
> just add the rectangle to a damage list, in preparation for...)
Indeed, but what interaction should it have with the deferDisplayUpdates
flag? I'm puzzled by the way that the win32 code for this does involve
deferDisplayUpdates. I suppose my concern is that if the inner vm code
has some subtle difference to other platforms we could see odd effects
since a great deal of graphics code is written by Andreas on windows.
For example, for several releases some time ago I didn't see any morphs
while they were being dragged because nobody had mentioned some change
or other involving force update and defer and blahblah. Don't recall
the details anymore but it was that general area.
> 
> ioForceDisplayUpdate() tells the VM that any screen updates from 
> previous calls to ioShowDisplay that have not as yet been forced into 
> the physical framebuffer should now be forced into the framebuffer.  
> (E.g., the Unix/X11 code calls XFlush() which returns after the server 
> tells us that all pending PixMap writes have been propagated to the 
> framebuffer -- which is kind of pedantic, but it does allow the image 
> to assume the user is now seeing the most recent Display contents at 
> the time the prim returns.  Other VMs might defer synchronising the 
> physical screen with the Display explicitly -- e.g., if they blit bits 
> directly out of the Display object and use ioShowDisplay() only to 
> maintain a damage list to avoid repaints of overlapping areas.)
That's fine; it would be nice to have better commenting of this where
possible. Again, the win32 code refers to deferDisplayUpdates which has
the same concern as above. Which code should take note of deferment and
which can or should ignore it (I guess any of it can ignore it at a
potential performance cost).
> 
> Any clearer yet?
Somewhat but it would be nice to get it documented more cleanly. Some
explanation of the pixel reversal when depth is -ve would be good to get
in as well.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: SFA: Seek Financial Assistance