[squeak-dev] Defer updates & drawings

Hello list,

from first time i tried to understand the logic of deferring updates
in Display & PasteUpMorph code and i'm still confused.

Things how i understand it is following:

you can ask VM to defer updates of screen.
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.
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.

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

Is it only me who think that two offscreen surfaces (one at language
side, second at VM side) is a bit overkill?


--
Best regards,
Igor Stasenko AKA sig.

On 07.11.2008, at 01:35, Igor Stasenko wrote:

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


World assuredCanvas form == Display

- Bert -

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

2008/11/7 Bert Freudenberg <[hidden email]>:
Hi Bert,

hmm, if you look at

WorldState>>assuredCanvas
        remoteServer ifNotNil:[^self assuredRemoteCanvas].
        (canvas isNil or: [(canvas extent ~= viewBox extent) or: [canvas form
depth ~= Display depth]])
                ifTrue:
                        ["allocate a new offscreen canvas the size of the window"
                        self canvas: (Display defaultCanvasClass extent: viewBox extent)].
        ^ self canvas

the line:

Display defaultCanvasClass extent: viewBox extent

creates a new form if current canvas is nil. And its not a
DisplayScreen class instance, its a Form.
Now i can't find a code, which restoring canvas if it was reset, back
to use canvas which having form == Display.

Aha... reading Andreas reply i found the place where canvas is set
back to Display canvas..
Its in #doDeferredUpdatingFor:

> - Bert -

--
Best regards,
Igor Stasenko AKA sig.

2008/11/7 Andreas Raab <[hidden email]>:
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.


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.