Re: [Squeak-VMdev] Host windows

[Andreas R. <and...@gm...>]

Hi Tim,

> > a) WTF are canvasss used? So far as I can work out the WorldState has a
> > canvas which is a FormCanvas on the Display.
>
> Canvas is a protocol that is used to draw things. We have different Canvas
> types for different purposes, from rendering on Forms directly, to
> transmitting drawing commands remotely, to creating Postscript.

Correct. Unfortunately the current Canvas protocol is (how shall we say...)
historically grown ;-) IOW, it doesn't really provide the neat high-level
abstraction that we'd like to have.

> > So far so good but they
> > also seem to be used in a few other places and that confuses me because
> > ther is a good bit of code that looks like it very explicitly wants
> > Display to be the target form. See for example
> > WorldState>forceDamageToScreen which explicitly does Dispaly
> > forceDamageToScreen rather than form....
>
> Probably WorldState should talk to its canvas instead of assuming Display.

Likely yes.

> All canvases understand "forceToScreen: rect"; this should be used
instead.

Yes. It might also be interesting to check out Tweak's displayWorld
implementation - here all of the Display related operations are routed
through CWorldPlayer's display variable (and display really could be any
kind of drawable surface such as a window).

> > b) Which canvas to use? It looks like FormCanvas is the best candidate
> > already in the system. We could subclass to make the assorted force...

That's what I would do (and have done - see CTransformCanvas).

> > messages go to our host window DisplayScreen analogues but then
> > BalloonCanvas and other subclasses of FormCanvas would need sometinhg
> > done. If I've understood it, we could consider changing FormCanvas to
> > send all those force... messages to 'form' instead and then the 'form'
> > could be an instance of HostWindow and we pass them on to the
> > HostWindowPlugin. I looked at some ofthe PluggableCanvas classes but
> > they all seem a bit ugly to me.

This (the effect of wanting to use BalloonCanvas etc) is actually one of the
reasons why a distinction of the responsibilities of drawing protocol
(Canvas) vs. display surface (Window) can be advantageous. By the end of the
day, if you have a native window which has a form to display all you need is
to vector forceToScreen: and getCanvas appropriately (not counting the
various fixes in the rest of the system).

> Have you looked at ExternalScreen and ExternalForm?

Bad examples for this case. Native windows are *much* simpler.

> > c) Once we have a canvas talking to the HostWindowPlugin, we open a
> > host window, display something on it, force the damage to screen (well,
> > window) and it's supposed to appear on the glass. Many of us need to
> > process pixels and we have that code in the VM so we can leverage that
> > with (probably) a few mods to factor it not to assume getting the
> > Display oop from specialObjectsArray. Pretty soon the OS is going to
> > send in a paint/expose type event for that window and current code will
> > fail. All the copies of platform code I have (a bit old but probably
> > not horribly out of date) handle a paint by calling fullDisplayUpdate
> > (Ian has a nice little optimisation to use any paint event clipping
> > rectangle) which explcitly gets the bitmap from the Display oop.
> > Clearly this isn't going to do any updating of other windows. As it
> > happens, RISC OS is ok with this due to a side effect of how I have to
> > keep a backing bitmap for each window. All I have to do is map from the
> > incoming window handle to the actual host bitmap and display some of
> > that. No problem except for the 'waste' of memory. If you want to get
> > the latest bits from inside ObjectMemory we will need a map from host
> > window handle to squeak bitmap oop. Easy way is to have an array held
> > by specialObjects that has the oops of the bitmaps used by all open host
> > windows. How else might one handle paint type OS events?

The way I'd do it is to completely ignore fullDisplayUpdate and friends.
Just send the paint events to Squeak and let *it* deal with it. The only
place where we move bits from here (Form) to there (Window) is in
#forceToScreen: - e.g., the sequence would look like:
* Drawing in Squeak
    -> calls forceToScreen:
    -> copies bits into Window
* Paint event in VM
    -> generates paint event for Squeak
    -> calls forceToScreen: to restore invalidated portion


Cheers,
  - Andreas