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.

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

Cheers,
   - Andreas