/boot/loader graphics support & extensibility

[Marcel Moolenaar]

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
xcllnt at mac.com