[lcdproc] 640x200 pixels

m mai3116@ritvax.isc.rit.edu
Tue, 23 Nov 1999 16:41:57 -0500


Actually, I ran into the same problems. What I have come to conclude, the
most simple and elegant solution is this. There will be a special output
driver for graphic displays. The graphic driver will be able to display
everything the text driver displays, but it will be enhanced. For example,
the horizontal and vertical bar graphs widgets will display per pixel column
and row, as opposed to a big 5 pixel block at a time. The text widget will
have a font associated with it. Etc. However, there will be things that the
graphic display can support that the text display can't, such is the nature
of such devices. Icon, and picture, and animation support will only be
available in the graphic version. However, along with these widgets, there
will be an alternate text representation of it that will be displayed if the
output is being sent through a text display driver.

just though of something: the text displays support 8 custom characters
displayed at once. What if we pixel map the text device, and when we need to
display a graphic element, we do a sort of display scan. It will flicker of
course, but if we display 8 characters, blank the screen, display the next 8
character, blank the screen, and we do that fast enough... we might get the
illusion of a graphic. It might look like one of those old radar screens for
air traffic controllers, but it might work :-)

In the LCDproc++ model of things, the screen layout is all relative. There
are no absolutes. You have to specify lengths based on percentages. For
example. This will make it easier to support graphic and text displays at
once.

So, all in all. The graphic driver will support everything the text driver
supports, but it will be enhanced. The things that are graphic specific will
have "alternative" representations that can be displayed on text displays.
 similar in concept to the alt="text" tag in html for the img tag that is
used for text based web browsers such as lynx )

Graphic support, however, is the lowest priority on the implementation
timeline. I will include it in the general program design when I code it,
but it won't be implemented until later versions.

--min idzelis
mai3116@rit.edu
http://129.21.134.1/lcdproc/




-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net