2008/11/7 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> In deferred mode all drawing operations should not appear immediately on
>> screen.
>> 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
manually.


>> 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 ;-)
>

Indeed :)

>> 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.

> Cheers,
>  - Andreas
>


-- 
Best regards,
Igor Stasenko AKA sig.