Re: [Squeak-VMdev] Host windows

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

In message <01af01c496b6$167fe030$b200a8c0@R22>
          "Andreas Raab" <and...@gm...> wrote:
[snip]
> 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 any chance of that being improved anytime (very) soon?

> > Probably WorldState should talk to its canvas instead of assuming Display.
> 
> Likely yes.
I imagine making Form cope with force.... (doing nothing?) would let us
clean that up.
> 
> > 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).
Hmm, ok since Tweak is our current 'getting paid' target that is more
important.
> 
> > > 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.
Yes, I rather thought that was the intention but it is, shall we say  a
litle muddied at the moment as you mention above. I was imagining a
litle cleanup of FormCanvas so that either a DisplayScreen or a
DisplayHostWindow (our current subclass of DisplayScreen that knows
it's host window handle in some abstract fashion) would work. 

> 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).
Never come across getCanvas before but it seems plausible. Not exactly
widely implemented in the standard system so it doesn't jump out as
important. And it seems a bit of a onetrick pony as well - nobody ever
gets anything other than a FormCanvas out of it! (normal 3.7 image)

[snip]
> > > 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

Well this might work in many cases but I see some worries.

For example it isn't actually true that "The only place where we move
bits from here (Form) to there (Window) is in #forceToScreen:" since
that ain't how RISC OS does it. I have to (currently and I'd like to
change it) do the actual bit moving from Display to an OS pixmap at
ioShowDisplay time along with telling the OS that the area has been
dirtied. Then next time I get a paint event I blit the appropriate area
from the pixmap to the glass. Costs me a shadow copy of the Bitmap for
the Display (and any other windows we open) but makes it very cheap to
handle paints. Since can paints come at a furious rate in RISC OS (where
the active window can be anywhere in the stack of windows) this has
some value.

Which makes the second worry; the potential delay and disconnect
between the paint event and the redraw. Given the potential for
scheduling to delay the eventual forceToScreen it could be out of date
- say another window has been brought to front in the meantime. Does
the OS in question actually blit really straight to glass, or is there
some clipping area set when the paint event was sent? It may simply not
be a problem for those GUIs where the active window is at the top but I
suspect it could be a pain in some cases. Basically I'm wondering if
there is some context in the paint event that would need to be dealt
with. IIRC this was a real issue in older VW vms because of some
windows detail that got in the way. Hopefully it has all gone now.

I also have the practical problem that when I did have handling for
'draw right now dammit' things got very slow. As long as we can allow
the VM to handle paints if it wants to I can do something for now and
see about changes later.

I'm sure some people must think " why does he bother with this weird
OS" but it's good for everyone to have some heterogeneity around - it
keeps us honest about portability. And besides, oneday RISC OS will be
the predominant OS and all other feeble pretenders will have to kneel
in submission rant, rave.....

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
How was Thomas J. Watson buried?  9 edge down.