On Feb 22, 2008, at 12:39 PM, Oliver Fromme wrote:
At the same time the VGA driver is abstracted from any
high-level details, like fonts or character sets. This
means that it's easy to write an accelerated driver for
some graphics hardware. You simply implement mode
setting and bitblt and you're good to go.
Yes, that'll work well for putting characters on the
screen. But I don't think it is suitable for generic
graphics operations, even (and especially) for drawing
single pixels.
True. What do you envision? How generic do you think
we should make it?
For me the difference between an abstraction solely
based on bitblt and an abstraction that includes a
couple more primitives is minimal. The key aspect is
that we should not have to duplicate 1000 lines of
code, of which less than 10% deals with the hardware.
This, for example, is a problem with syscons and the
keyboard- and video switch interfaces. The keyboard
switch interface alone has 18 functions???? That's a
bad abstraction, nothing else.
You bitblt the 4 edges. I didn't say it was the most
performance optimal thing to do. I only said that it
can be abstracted that way.
I'm sorry, I should have been clearer, that gfx_rect()
function draws a filled rectangle.
I see. In that case it's a single bitblt operation :-)
For the loader, I plan to support bitmaps in an upwards-
compatible way. E.g. you should be able to use a 4bit
PCX file in 8bit and 24bit modes (but not the other way
round).
That's an excellent plan.
But I need to keep all those future enhancements in
mind, even if they're not first priority, or otherwise
it might become more difficult later on to add those
features. I also want to avoid breaking the syntax of
FICL words once they're established. That's why I
have to think about all that now.
Yes.
I think performance is not a concern.
Once you have the basic functionality, you'll also have a
wishlist of things you want to do better; performance one
of them in all likelyhood.
Performance isn't my highest priority, but not the lowest
either. I try to do things in a way so that they're not
horribly inefficient. At the very least I try to do it
in a way so that they can be made more efficient easily.
Agreed. Be aware of making the mistake to separate and
distinguish between variations of a single operation at
too high a level. For example: it's much more costly to
separate vertical line drawing from horizontal line
drawing from any other kind of line drawing at the MI
layer, than it is at the hardware level. The hardware
level needs to check the parameters anyway and unless
there's hardware acceleration it'll perform separate
code paths most of the time. The upshot of a single line
drawing primitive is that you don't have to worry about
the coordinates and which API function you must call.
This is important when the coordinates are parameters
to some function and you'll find yourself coding like:
if (isvertical(x1,y1,x2,y2))
drawline_vertical(...)
elif (ishorizontal(x1,y1,x2,y2))
drawline_horizontal(...)
else
drawline_generic(...)
With hardware acceleration you may not have to care at
all and when you need to draw the line in software,
you need to test the coordinates anyway and split the
work based on angle even. In that case you also split
horizontal and vertical.
Anyway: that's enough out of me. I think what you're
doing is great and I can't wait to see it realized...
--
Marcel Moolenaar
[EMAIL PROTECTED]
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
