[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] XaAES bugtrack (admin and) feature requests
>> Speaking of gradients - this should really be a VDI feature. It could be
>> implemented as a variant of v_bar(). This way XaAES does not have to bother
>> with pixel format detection, and (I don't know if graphics cards can do
>> gradients in hardware) possibly speed up things.
>
> I totally agree.
> Putting a low-level drawing feature like gradients in the AES is a nonsense,
> it has do be done in the VDI.
Well, besides the problem of supporting old VDI:s, there are a couple
of major problems with VDI level gradients, as I see it:
- What kind of gradients should be supported?
+ top to bottom - obviously
+ left to right - I suppose so
+ corner to corner - possibly
+ any angle - well...
+ elliptical, polygonal, etc - uhm...
- To what kind of drawing should they apply?
+ Boxes - obviously
+ Rounded boxes - I suppose so
+ ellipses, polygons - well...
+ lines, text, etc - uhm...
- How should the colours be defined?
+ Extra palette entry for second colour perhaps?
+ Special gradient palette entries?
- How should the gradient itself be defined?
+ Linear in RGB?
+ Linear in some more suitable colour space?
+ Not linear at all? How then? Gamma?
And how do you get decent performance?
The preferred implementation depends on the use case. Some methods use
up lots of memory, but can be much faster than others, especially if
the gradient is going to be used more that once. And in the case of a
graphics card, you may want to allocate memory on the card for
pre-created gradients, or not.
In all, I don't believe that the VDI could make the "right" decision
regarding how to do the gradient. I'd rather see VDI support for
making the various gradient choices possible, with good performance.
Such as:
- Off-screen, but on card (when applicable) bitmaps
To make use of the really high bandwidth that the graphics cards
have internally.
- "area-fill-blits"
Blitting a block repeatedly, to fill some shape (possibly only rectangular).
- "poly-blits"
Blitting the same thing to many places with a single drawing call.
- Masked blitting
Using a binary (or alpha) mask to specify where a blit (including
the ones mentioned above) actually goes.
- Multi-coloured poly-lines
For simple gradients that do not require the setup of bitmaps for
blitting, and other things.
Several of these would be very useful not only for gradients, but for
texture mapped backgrounds and games as well.
/Johan