Alan,

	The DisplayScreen class is intended to define a display surface for Squeak (specifically BitBlt objects) to interact with.  How the global Display object gets rendered on a physical display device is a target specific implementation issue.  The #depth:width:height:fullscreen: selector calls primitive 92 to let the VM know that a request has been made to change the size of Display, but what the VM does as a result of this request is target specific.

	As an example, the Win32 VM tries to resize the Squeak window in the Windows environment to the requested size.  It never tries to change the actual video mode.  I would only consider interpreting the request as a request to change the video mode if the fullscreen: parameter evaluates to true, and even then this is debatable.

	Regarding working in other color spaces, there is certainly opportunity to explore this area.  You may want to talk to Andreas Raab about this.  I'm sure he has at least thought about it some.

					-Dean


> -----Original Message-----
> From: Alan Grimes [mailto:alangrimes at starpower.net]
> Sent: Monday, March 10, 2003 3:07 PM
> To: The general-purpose Squeak developers list
> Subject: Design Issues: DISPLAY
> 
> 
> om
> 
> In working on the design of the framebuffer driver I have 
> come across a
> number of design issues that need to be addressed. 
> 
> [RESOLUTION]
> The first issue has to do with a class method for the class behind the
> Display object. The method allows the user to resize the Squeak window
> to any arbitrary dimensions and bit deapth. 
> 
> Even though some hardware configurations do allow one to configure the
> DAC to generate arbitrary resolutions it should not be 
> expected that the
> monitor will easily support such resolutions. For that reason, Squeak
> should support only the VESA mode tables... One implementation of this
> would take the user inputted X,Y,Colors, look it up in the 
> table. If the
> resolution is validated in this way, the request is sent to 
> the card and
> the resolution change takes place. Otherwise, the request is 
> rejected. 
> (1024x768x16 is accepted while 1000x800x20 is rejected) 
> 
> A more elegant solution would be to redesign the interface to Display
> with a method: videoMode:  which would accept a VESA video mode as
> input. Ofcourse this would have limitations and portability 
> issues... =\
> 
> Another possibility is the driver establishes an off-screen buffer at
> the desired resolution, sets the monitor to the next smallest 
> resolution
> and then BLTs the data onto the screen through some transformation.
> 
> Another option would be for something inside the immage to do the
> transformation before sending it to the driver...
> 
> All of these have their benefits and drawbacks...
> 
> 
> [COLOR]
> The second issue has to do with color. As of now, Squeak 
> assumes that it
> lives in an RGB universe. That is just fine but many things prefer YUV
> color spaces instead... An example is my 10 year old video card which
> supported off-screen buffers on which it could do color-conversions,
> scaling, and a number of other transformations. A video card with this
> feature can allow even a pentium 100 to display good 
> full-screen video.
> While the linux kernel is probably much too primative to support these
> Windows 3.11 *ghasp* features, we should be planning for this kind of
> hardware support. 
> 
> It would seem that the design solution would be to either extend the
> FORM class, or create several variants of FORM that support 
> the varrious
> color spaces... 
> 
> The issue becomes controlling the video card to allocate the
> alternate-color-space buffer, and then display it in the appropriate
> Morphic window...
> 
> I have only been looking at the Unix variant of the squeak VM, I don't
> know how these issues interact with other operating systems. 
> 
> Being such a newbie as myself I know that I am not qualified to solve
> these problems with the grace and elegance that is so customary in
> squeak. 
> 
> -- 
> Karl Marx is smiling.
> http://users.rcn.com/alangrimes/
>