Re: [Squeak-VMdev] Host windows

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

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

OK, I'll see if I can untangle enough to make a crack at it.


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

Ah - cross purposes here. On ROS ioShowDisplay doesn't put pixels to
glass; it _does_ move them from Form to window-backing-pixmap, doing
the endian/RGB->BGR transform on the way. Actual pixels to glass is
done when a paint event is processed. ioShowDisplay tells the OS that a
certain area has been dirtied and thus triggers the paint event at
the next handleEvents opportunity.
That's the split that was annoying me - ioShowDisplay gives us a handle to the
Sq bitmap so it is possible to grab pixels directly and send them to glass if
that is how your OS works. At paint-event time we don't have a convenient handle
to the Sq bitmap _unless_ we make the assumption that it must be
Display. Which is of course a bad assumption as soon as we have
multiple windows.
The obvious corollary is that if paint events only pass the damage
rectangle up to the image, then ioShowDisplay is called to move pixels
to the buffer and that is it. No actual displaying to glass. If I left
in the code to report the damage area I'd get a nice loop :-)  So any
VM that buffers the window has to actually handle the paint events and
not pass them up, and we have to remember not to put anything in the
image that relies on getting those events. That's all I meant when
refering to portability.

John mentioned that OSX is double buffering the windows so it might be
an issue for him. And I hear the M$ is making big changes in their
graphics model for this avalon thingy; maybe they'll require apps to
report damage areas and only display pixels during a paint event handler
critical block?


[snip]
> 
> 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).
You've made my point for me. I hope there is no problem but I remember
that there used to be and thus we need to remember the issue before
charging off down a box canyon. That's all. 

> > 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 ;-)
Well of course, but portability includes across time not just current
platforms. If M$/Apple does something dramatic in a future OS release
you'll be just as happy that we spent time on it as I want to be now -
probably more so because you (as in win32 vm) have millions of probably
screaming users whereas I only have a thousand or two to pacify.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: XI: Execute Invalid op-code