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/