Re: [Squeak-VMdev] Host windows

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

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

Soon yes. Very soon probably no.

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

Sounds like an excellent idea to me.

> > 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:
[...]
>
> 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.

Well, maybe not but forceToScreen: indeed calls (via
primitiveShowDisplayRect via displayBitsOf) ioShowDisplay (which does move
the bits) and my point is that this is the only place where this is
required.

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

Sure - and that's precisely what forceToScreen: asks you to do ;-)

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

The portion of interest from the paint event is the invalidated region.
Everything else is (AFAIK) irrelevant on pretty much any platform. While
there are additional contexts that may be passed along one should be able to
recreate them from the information we have (this is true of Windows for
sure).

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

That's what we have forceDisplayUpdate for ;-) Some renaming might be in
order but the Windows VM had done this for years and forceDisplayUpdate was
introduced for the precise reason to force a synchcronous update of display.

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

Everything to keep you happy, Tim ;-)

Cheers,
  - Andreas