Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000830 [tweak] Any major always 01-14-05 08:52 01-15-05 05:41
Reporter tim View Status public  
Assigned To
Priority normal Resolution open  
Status new  
Summary 0000830: Host Windows: suggested extension to update protocol of primitive
Description 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.
Additional Information
Attached Files

- Relationships

- Notes
(0001080 - 627 - 627 - 627 - 627 - 627 - 627)
andreas
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.
 
(0001083 - 2329 - 2425 - 2425 - 2425 - 2425 - 2425)
tim
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.
Thus,
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.
 
(0001084 - 1955 - 2105 - 2105 - 2105 - 2105 - 2105)
andreas
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?
 

- Issue History
Date Modified Username Field Change
01-14-05 08:52 tim New Issue
01-14-05 09:05 andreas Note Added: 0001080
01-14-05 21:17 tim Note Added: 0001083
01-15-05 05:41 andreas Note Added: 0001084


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
40 total queries executed.
31 unique queries executed.
Powered by Mantis Bugtracker