Lazy Display init (Was: Re: [ENH] Splash screen)

David T. Lewis lewis at mail.msen.com
Tue May 23 02:26:36 UTC 2000


On Mon, May 22, 2000 at 11:40:35AM +0200, Bert Freudenberg wrote:
> On Sun, 21 May 2000, Tim Rowledge wrote:
> 
> > In message <20000521112246.A24406 at conch.msen.com>
> >           "David T. Lewis" <lewis at mail.msen.com> wrote:
> > 
> > > On Thu, May 18, 2000 at 09:33:08PM +0200, Bert Freudenberg wrote:
> > > > On Thu, 18 May 2000, Tim Rowledge wrote:
> > > > 
> > > > > One part of this could be done by adopting the changed semantics of
> > > > > beDisplay that I use on the Acorn; the window is not created
> > > > > until/unless that prim is called.[snip]
> > > 
> > > Actually, I did this once before, based on Tim's suggestions. I'm attaching
> > > a copy of my earlier message.
> > That's an interesting way of handling it. I did it all within the Acorn
> > specific vm code to avoid any need for persuading people to incorporate
> > image changes in such a sensitive area. We should probably revisit the
> > idea properly sometime.
> 
> Now is the time ;-)

The changes in the sensitive area are really trivial. I hung my system
a few times figuring them out, but no problem otherwise.

> 
> I suggest naming it ioOpenDisplay(displayOop) for consistency with the
> other io functions. The default implementation would just return 1.

Yes, that's better.

> 
> Then, we could start thinking (again) about multiple OS windows. We would
> need some more primitives that take a display id. The id would be returned
> by ioOpenDisplay and used in ioForceDisplayUpdateID, ioScreenSizeID,
> ioSetCursorID, and ioShowDisplayID. To make input easy to implement there
> could be the concept of a "current" display (which corresponds to an
> active OS window). Functions ioMousePoint, ioGetButtonState,
> ioGetKeystroke, ioPeekKeystroke would answer the values for the current
> display. In addition we'd need ioCloseDisplayID and ioActiveDisplay() or
> something similar.

This sounds right for the display side. Keep "ioForceDisplayUpdate"
for backward compatibility, and gradually replace it with
"ioForceDisplayUpdateID: anID".

The input functions (ioMousePoint, etc) can probably use the implied
"current" display as you suggest. There will also need to be a more
general way of dispatching input events to their correct displays.
Initially this can go into the ioProcessEvents() loop. Event queues
would be nice but perhaps can wait until later.

> 
> On the Squeak side, a world would have a DisplayScreen instance to draw
> on. Input should be moved to DisplayScreen, too. Or better yet, make a new
> DisplayScreen subclass Terminal which sort of merges InputSensor methods
> into DisplayScreen. A PhysicalTerminal would hold the ID. All
> PhysicalTerminals need to be known to the VM via a special objects array
> to access their display bits for redraw. The "current" world would be the
> one which can get input, while the others are output-only and run
> doOneCycleInBackground (if needed).

Remembering the recent creative flurry involving punch card morphs, I would
lobby to implement PhysicalTerminal with an RJE metaphor, complete with
reader, punch, and printer queues. In keeping with standard X window
protocols, everything should be bass ackwards, so Squeak would take the
part of the client RJE station communicating with the host window server.

Squeak would receive incoming events on its punch queue, and write back
to the server on its reader queue. X protocol errors would be routed to
the printer queue. While admittedly somewhat confusing, this scheme would
have the advantage of permitting X protocol transactions to be displayed
on Bob Arning's PunchCard morphs.

> 
> How does this sound?
> 
> -- Bert
>

Good. Let's do it. Except for the RJE part.

Dave
 





More information about the Squeak-dev mailing list