Subject:
RE: Truecolour, Pseudocolour
From:
Greg Haerr ####@####.####
Date:
21 May 1999 20:45:51 -0000
Message-Id: <01BEA398.697A1EC0.greg@censoft.com>
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
