[squeak-dev] Re: Defer updates & drawings
siguctua at gmail.com
Fri Nov 7 17:23:43 UTC 2008
2008/11/7 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>> In deferred mode all drawing operations should not appear immediately on
>> But once you disable it, you can force portion of screen to be updated
>> by using #forceToScreen: message.
> Basically correct.
>> What is interesting that you can force to update a portion of screen
>> regardless being in deferred more or not, and it will update the
>> window immediately.
> Why is this "interesting"? Implicit updates are only done when using BitBlt
> but one can easily imaging using other Display manipulations and for that
> you do need the explicit update.
I now understand why sometimes , it leaves dirty areas on screen -
because if you draw bypassing damage recording, then World thinks that
dirty areas are still clean, and user needs to force redraw the window
>> Deferred mode implies, that somewhere under the hood, VM or OS keeping
>> an offscreen surface in operative memory and then will use it to
>> draw/swap on screen in single shot.
> Yes. That form is Display.
>> Now, second thing, if you look through code, how PasteUpMorph works
>> with Display, it acquring an #assuredCanvas , which in own turn
>> makes sure it gets new, fresh __offscreen__ form , having same
>> dimensions as current Display to draw into it.
> Not quite. The code in assuredCanvas is only used for embedded worlds; not
> for the "primary" world. For the main World, it is actually being set via
> WorldState>>doDeferredUpdatingFor: (see the "non-proper" display case at the
> bottom). This can be somewhat confusing ;-)
>> Is it only me who think that two offscreen surfaces (one at language
>> side, second at VM side) is a bit overkill?
> There is only one offscreen surface (Display).
Thanks for reply. It was very helpfull.
> - Andreas
Igor Stasenko AKA sig.
More information about the Squeak-dev