[Squeak-VMdev] Host windows

[Tim R. <ti...@su...>]

(Mostly to Andreas but it affects several people and probably interests
more)

John passed on to me (briefly, on a bad cellphone link, so excuse any
misunderstandings) the comment about hooking into the
forceDamageToScreen/forceDisplayUpdate instead of into the
displayBitsOfLeftTopRightBottom end of copyBits (et al.). Excellent
suggestion; it avoids the unpleasantness of how to check to see if this
is a Display or host window within a rather common operation.

(For other people, my first and actually functional hack, was to extend
displayBitsOfLeftTopRightBottom such that any bitblt to a host window
would trigger the ioShowDisplay mechanism just as Display does now. It
works great but meant adding a hopefully-fast way to check for
'destination is some kind of host window'. Ugly, limits you to one
class etc but it does make it really simple to display stuff on the
extra windows since any bitblt at all with the window as a dest will
cause an update immediately)

Moving the window updating to a plugin call attached to
forceDamageToScreen means it can work with the Canvas mechanism.
However, I have queries about some details her since I have no prior
experience with doing anything to canvases.

a) WTF are canvasss used? So far as I can work out the WorldState has a
canvas which is a FormCanvas on the Display. 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.... and  FormCanvas>flushDisplay
which again talks to Display rather than the target form. It's
understandable that this might be done with only a single window,
though it seems a waste of time when the target form is not the Display.

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

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?

d) my knuckles hurt. enough

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful random insult:- Afraid she'll void her warranty if she thinks too much.