nanogui: Thread: Truecolour, Pseudocolour

I just came to add the readpixel() to the bogl-tcfb and bogl-pcfb drivers,
and wondering whether I should make it a common function for both drivers
in bogl-cfb.c or not, decided to compare the two files to see what the
difference is in the way the two modes are handled. It turns out that 
apart from the naming differences, about 99% of the code is exactly the
same. Is it planned to diverge the two further in future for optimisation
reasons, or would it be a better idea to combine them into one driver?

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

Alex Holden ####@####.#### writes:

   I just came to add the readpixel() to the bogl-tcfb and bogl-pcfb drivers,
   and wondering whether I should make it a common function for both drivers
   in bogl-cfb.c or not, decided to compare the two files to see what the
   difference is in the way the two modes are handled. It turns out that 
   apart from the naming differences, about 99% of the code is exactly the
   same. Is it planned to diverge the two further in future for optimisation
   reasons, or would it be a better idea to combine them into one driver?

I'm not sure what ####@####.#### had in mind.  I'll try to take a look
today or tomorrow.  I'm sure that it would be fine to combine them if
it wouldn't mean a big performance hit.
-- 
"It takes a certain amount of shamelessness
 to be a monomaniac billionaire dwarf."
--Jon Katz <URL:http://slashdot.org/articles/99/03/17/1634238.shtml>

On 21 May 1999, Ben Pfaff wrote:
> I'm not sure what ####@####.#### had in mind.  I'll try to take a look
> today or tomorrow.  I'm sure that it would be fine to combine them if
> it wouldn't mean a big performance hit.

The only real difference is a couple of extra lines in the setup routine
of one of them, all the rest of it is the same.

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

Alex Holden ####@####.#### writes:

   On 21 May 1999, Ben Pfaff wrote:
   > I'm not sure what ####@####.#### had in mind.  I'll try to take a look
   > today or tomorrow.  I'm sure that it would be fine to combine them if
   > it wouldn't mean a big performance hit.

   The only real difference is a couple of extra lines in the setup routine
   of one of them, all the rest of it is the same.

Then I would say, go ahead.
-- 
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver."
--Daniel Pead

On Friday, May 21, 1999 5:11 AM, Alex Holden ####@####.#### wrote:
> I just came to add the readpixel() to the bogl-tcfb and bogl-pcfb drivers,
> and wondering whether I should make it a common function for both drivers
> in bogl-cfb.c or not, decided to compare the two files to see what the
> difference is in the way the two modes are handled. It turns out that 
> apart from the naming differences, about 99% of the code is exactly the
> same. Is it planned to diverge the two further in future for optimisation
> reasons, or would it be a better idea to combine them into one driver?
> 

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?

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 much as getting the project 
moving forward quickly, on multiple platforms and multiple screen devices.  It's these
things that MUST be done first, in order to assure portability in the future without
alot of rehacking...

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...

What do you think?

Greg

On Friday, May 21, 1999 8:52 AM, Alex Holden ####@####.#### wrote:
> On 21 May 1999, Ben Pfaff wrote:
> > I'm not sure what ####@####.#### had in mind.  I'll try to take a look
> > today or tomorrow.  I'm sure that it would be fine to combine them if
> > it wouldn't mean a big performance hit.
> 
> The only real difference is a couple of extra lines in the setup routine
> of one of them, all the rest of it is the same.
>

IMHO, all the shared code should be moved to another separate file.

gh

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/ --------------------

On Friday, May 21, 1999 2:23 PM, Alex Holden ####@####.#### wrote:
: On Fri, 21 May 1999, Greg Haerr wrote:
: 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).
: 

	I agree.

: > 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.]

	There are all sorts of performance issues, if we really want
to get into performance now.  See my comments in the code commented
out in srvdraw.c.  Basically, performance in graphics is a code size
tradeoff.  Presently, until we get this thing fully working, *and* someone
starts complaining about speed, the architectures I'm suggesting
will definitely handle it.  As an example, clipping vs not on a per-pixel
or line basis is infintely slower than some of the stuff we're talking about.

: 
: > 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, 

	Totally agree.

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?

	The only thing I'm proposing is grouping together routines for the
same hardware, which at this point are the VGA drivers.  For GGI based
stuff like you're talking about, we are going to need totally different drivers,
just like you're talking about.  So I'm just trying to get the "VGA" drivers
put together in *one* place so that we don't have 5 versions of them.  What
we want is *one* VGA driver with variations, then a GGI driver, and BIOS driver, a 
XXX driver, etc.
	
	Back to the hardware line draw, etc, that's covered by filling in the
proc ptr's in the SCREENDEVICE struct.  BTW, the GGI issue is a good one
for dealing with the BITMAP structure's etc we've been talking about this week.
For example, it's *very* unlikely that GGI has a hardware address that you can draw
stuff on, like a virtual screen.  Instead, it's undoubtably yet another abstracted api
that our SCREENDEVICE api will have to talk to.  (and this works, at least
according to Vidar, although his port brings up more issues, which he wanted some
work done with...)

Greg