Re: [Squeak-VMdev] Host windows

[Ned K. <ne...@bi...>]

On Thursday 09 September 2004 1:05 pm, Tim Rowledge wrote:
> (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. 

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.

Assuming that a Canvas is anything in particular is asking for trouble.

I am making a new kind of Canvas that is an interface to the Cairo library; 
Cairo provides back-ends for host window display surfaces, for bitmaps in 
memory, for PDF output, and for OpenGL textures.

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

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

It is likely that we'd want to have a World that lives in some other kind of 
Canvas.

> and  FormCanvas>flushDisplay 
> which again talks to Display rather than the target form.

And isn't called, and should be removed.

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

But forceDamageToScreen and flushDisplay are only used (should only be used, 
anyway) when it's clear that we're rendering to 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.

Have you looked at ExternalScreen and ExternalForm?

> 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.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev

-- 
Ned Konz
http://bike-nomad.com