Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Johan Klockars <johan@klockars.net>]

>> For anyone else who is reading this, and has not read my latest post
>> in ARAnyM list (or related ACP list posts), I am proposing the same
>> additions of ASM to XaAES (along with full AES implementaions) to be
...
> I can see the benefit in assembler if you try to optimize a line-drawing
> routine - but there are no such things in the AES. The AES is separate
...
> nowhere else. When it comes to performance, well designed (and implemented!)
> algorithms in C are hard to beat. For such a big project, the compiler will

I would also be surprised if there are areas of the AES itself where
significant amount of time are spent.

> Having the VDI as a kernel module so the AES can call it directly will be a
> huge benefit performance-wise.

The standard VDI call interface is brain-dead, and direct calls would
indeed speed up some things. Most things in fVDI do have both standard
and "smart" interfaces already, so that wouldn't be hard to do.
Making fVDI a kernel module is definitely a priority.

There is also quite a bit of potential for speeding up the AES by
adding new functionality to the VDI (or use already existing
functionality better).
For example, let the VDI control background saves and data for icon
like objects. That way they can be cached in graphics RAM (without the
kind of "cheating" I do in the RageII driver ;-), which can speed
things up immensely.
Doing line drawing in larger batches is another thing that can help.
There is already support in the VDI (well, at least the Bezier capable
ones) for poly-lines with gaps. This could be extended to allow for
colour variations, which could give you single-call gradient filled
rectangles.
I'm sure there could be a use for some extended variation of
poly-markers as well.

Other ideas for performance enhancing features are welcome.

/Johan