Mantis - tweak
Viewing Issue Advanced Details
830 Any major always 01-14-05 08:52 01-15-05 05:41
0000830: Host Windows: suggested extension to update protocol of primitive
Currently the update prim expects the oop of the bitmap as one of the arguments. I can see plausible platform circumstances where it might be more useful to have registered the bitmap as an external object (as we do for semaphores) and to pass the registry value.

This would make it possible to find the bitmap address at any time, not just when it is passed to the update prim, rather like fullDisplayUpdate takes advantage of the Display oop being held in the specialObjectsArray. I can imagine this being of use to platforms wanting to make use of a similar facility for redisplaying secondary windows when they are moved to the top of the z-order for example.

Since the HostWindowProxy classes insulate any client code from such concerns this would be a completely private choice and only requires a trivial extra prim to use instead of the current one. Either or indeed both could be used at need.

01-14-05 09:05   
I can't see any sensible reason whatsoever for wanting to register a display bitmap with the host window - the only effect we'll get is that a) the implementation gets more complex (have you ever tried to explain to someone why we call fullDisplayUpdate when we see an expose event in the VM and why this would call ioShowDisplay ;-) b) makes the implementation more brittle (expose events may indeed come halfways through a garbage collection if you aren't careful) and c) we might easily display inconsistent state (halfways through rendering) when actually using it. In short, I see not a single advantage in going that way.
01-14-05 21:17   
Why fullDisplayUpdate is used as a response to expose events in some VMs - easy to explain.
Windows lets you update the screen when you want to. This allows the VM to move pixels to the screen when ioShowDisplay is called by the image. However, there are occasions when the UI wants to order a screen update and the VM cannot simply call ioShowDisplay because the address of the Display bitmap is not known at that point. To handle this eventuality, fullDisplayUpdate is used and extracts the bitmap address from the oop of the Display kept in the specialObjectsArray for exactly this purpose.
a) image wants to display pixels -> use ioShowDisplay which expects the bitmap address to be passed to it
b) OS/UI wants to dispaly pixels (window moved, changed z-order) -> use fullDisplayUpdate which finds the bitmap oop and 'fakes' an ioShowDisplay.

fullDisplayUpdate is effectively using a registered bitmap. I am simply suggesting that the same facility might be useful for some OSs when making multiple host windows.

If expose events can come part way through a GC ((not in my VM they can't) then the current fullDispalyUpdate system would fail. Does it ever?

I think perhaps you misread my use of registering the bitmap; I did not mean any connection of the bitmap to the host window - sometihng I vaguely recall might be possible with a windows structure extension - but simply putting the bitmap oop into a registry like the external objects registry used to make the input semaphore into an int for the VM to use without relocation problems.
For example, I would use this to keep the ioShowDisplay as simply tellingthe UI that a certain area of a particular window has been damaged. Later, the event loop gets the paint event and finds the appropriate windowdescriptorblock, which has the bitmap index whcih leads to the correct bitmap oop and address. For windows, it would mean that fullDispalyUpdate could be trivially expanded to take the window index as an arg for the same purpose.

But, the nice thing about a bridge pattern proxy is that I don't have to care how you implement anything on the private side of the bridge; you could ignore the plugin and use FFI calls if you like. In fact I think I'd recommend that since you have a good FFI implementation.
01-15-05 05:41   
It has always been my understanding that the best way to design asynchronous communication between image and VM is to allow the VM only a single asynchronous operation: Signaling a semaphore. This is how sockets work, this is how files work, this is how user input works and this is how everything that's potentially asynchronous should work. Everything else should then be invoked from the image.

I have cursed the exposure of the Display object to the VM many more times than I can think about and I have been happy to see that this particular design flaw wasn't repeated in the host windows stuff. Since we have paint events we can avoid the exposure of Display (or any other) oop to the VM in this area. It means that the interface is simpler, it means that clients can choose to have multi-threaded implementations (or not), it means that the image does not need to have to worry about being shot in the foot or crashing if the oop goes away, it means we don't have to wonder about who still refers to that oop, etc. etc. etc.

You are essentially proposing to change this model for no better reason than "it can be done" or "it may be useful". Please, don't fix what isn't broken.

  "If expose events can come part way through a GC ((not in my VM they can't) then the current fullDispalyUpdate system would fail. Does it ever?"

If you have a multi-threaded implementation it does.

  "But, the nice thing about a bridge pattern proxy is that I don't have to care how you implement anything on the private side of the bridge ..."

True, but at the same time your level of abstraction goes down - now we're suddenly at a level where we can no longer presume we have a common level of abstraction in the image. That's a bad practice since people will program to their individual idiosynchracies instead of common abstractions (take file names for example).

PS. As a discussion medium this sucks. How about taking it over to VM-dev?