nanogui: frame buffer part 423423512435
Subject:
Re: frame buffer part 423423512435
From:
"Greg Haerr" ####@####.####
Date:
5 Feb 2000 03:24:35 -0000
Message-Id: <033001bf6f86$ee20efe0$15320cd0@gregh>
: 1) framebuffer (fake or virtual or real) that only offers very minimal
: functionality , address pointer for framebuffer access and init (mode
: switch
: function)
:
: + this makes the kernel part very small and "easy" which is good.
Very very good for embedded and small systems.
: - the number of different pixel formats is large and the framebuffer
: must
: offer the graphics libary info about the organisation of the
: buffer.
No big deal. Getting height, width, linesize, bpp and address are basically
enough. I've got code for drawing on all sorts of different pixel formats
already.
: - hardware acceleration isn't realy posible without extra interfaces
No problem for rev 1. Microwindows doesn't do hw accell either
at this point, and if it the designer needs it, it doesn't yet have to go into
the kernel. There are trillions of issues with hw accelleration. Take
a look at the DirectX driver API for good details ;-)
:
: 2) device driver like table with functions like draw pixel, switch mode
: , etc.
: + very fixed and defined interface
Actually, no. We're not yet at the point of defining a good, stable
interface. And it'll end up being quite large if we had to. Every new
acceleratable feature in Microwindows, for instance, might have to
add another entry point.
: + the line drawwwing for example could be hardware accelerated
This won't buy much now. Fast byte move CPU instructions will work
just fine.
: + the graphics libray can concentrate on graphics and not on hardware
Yes
: + BSP providers can offer a easy interface to graphics hardware.
Well, in rev 1, thats what the fb is for.
: - the number of possible hardware accelerated functions can grow
: rather large.
:
Very.
:
: I think point 2 is the more interesting one , cause it hides more of the
: hardware behind
: a wel difent interface. Things like line drawing can be optimized in
: assembly which
: make them CPU dependend which is probebly something you cant to keep out
: of yer graphics
: libraries.
At this point, noone wants to write asm routines for all the graphics stuff,
for each different chip. Way too much work for rev 1. The whole point of
Microwindows is to bring a small, easy, portable graphics system to
more developers WITHOUT having to write more low level code.
It also makes it easier to add "strange" hardware which
: doesn't directly
: have a memory mapped framebuffer, or useses some window due to lack of
: address space
: or cost reduction in hardware.
Strange hardware that can't map a framebuffer shouldn't necessarily be
the first consideration. Especially when we don't have the easier chips
working.
I strongly think that your Option #1 is the way to go. Especially to keep
things simple. Keeping things very simple will allow for more programmers
to contribute to this project, which will be needed to get all the chipsets
done.
:
: Maybe we should make a list with operations that we need on a graphics
: display ?
See the SCREENDEVICE struct in Microwindows' device.h for a start.
But I don't think the kernel should get involved with this. That's what
Microwindows is for.
Greg
