nanogui: Truecolour, Pseudocolour


Previous by date: 21 May 1999 20:33:16 -0000 Re: Nano-X-0.5pre3, Alex Holden
Next by date: 21 May 1999 20:33:16 -0000 Re: Nano-X-0.5pre3, Greg Haerr
Previous in thread: 21 May 1999 20:33:16 -0000 Re: Truecolour, Pseudocolour, Greg Haerr
Next in thread: 21 May 1999 20:33:16 -0000 Re: Truecolour, Pseudocolour, Greg Haerr

Subject: RE: Truecolour, Pseudocolour
From: Alex Holden ####@####.####
Date: 21 May 1999 20:33:16 -0000
Message-Id: <Pine.LNX.4.04.9905212112340.1204-100000@hyperspace>

On Fri, 21 May 1999, Greg Haerr wrote:
> Alex, I'm so glad you are doing this, because now you can understand
> what I've been suggesting:  we should think about keeping some *common*
> source to these routines, and share them between all framebuffer
> drivers.  Yes, they may be a little bigger, but it sure beats
> re-implementing the same damn thing over and over again, right?

Only if it doesn't affect the performance much. Apart from the obvious
pcfb/tcfb being pretty much the same file mistake, and the fact that cfb8
is now obsolete, I don't think there's a lot that can be done to combine
things more. In some areas, it might well be a good idea to split it up a
bit to improve performance (ie. base nearly all of the drawing routines on
a common putpixel() routine, which instead of using a switch(bpp) like it
does now, has seperate routines for different bit depths, which are
selected at initialisation).

> My plan all along is to continue to abstract common code to more
> levels.  I'm not so worried about nano-X getting too big just yet, as

This is only a good idea if it doesn't affect performance significantly.

> I've got a common planes driver now for dos, elks, and linux.  I'd very
> much like to see a common packed pixel driver as well.  These drivers
> are above the framebuffer level.  They are common code and only use the
> framebuffer code to get the mmap() screen pointer.  Then we can use them
> on any OS that happens to be running an EGA/VGA card...

I can see how that would work for simple setups, but what about running on
top of GGI, or accelerated drivers which use the hardware to do tasks like
drawing lines? We can't abstract away the whole lower layers as that
wouldn't cater to wierd situations like using GGI, or add in too many
layers as that would affect code size and performance. What are you
actually proposing to change from the current setup?

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------



Previous by date: 21 May 1999 20:33:16 -0000 Re: Nano-X-0.5pre3, Alex Holden
Next by date: 21 May 1999 20:33:16 -0000 Re: Nano-X-0.5pre3, Greg Haerr
Previous in thread: 21 May 1999 20:33:16 -0000 Re: Truecolour, Pseudocolour, Greg Haerr
Next in thread: 21 May 1999 20:33:16 -0000 Re: Truecolour, Pseudocolour, Greg Haerr


Powered by ezmlm-browse 0.20.