Re: [MiNT] Cool new AES features

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Wed, 2005-07-06 at 23:32 +0200, Zorro wrote:
> Yes, unoptimised.

Cairo currently isn't very optimized for the non-hardware-driven
backends.  It is however growing in popularity and embracing it now
could very well make software porting much easier in the future.  The
optimization issue should change shortly.  Evas was designed for
embedded systems with limited memory and CPU power, and no hardware
acceleration, although it can also output to OpenGL as well for hardware
acceleration.

> Have you studied the cairo code? I have do that to make my PDF codec.
> 
> I don't know EVAS but I'm sure that it can't handle directly Bitmap in 
> Atari format.

I follow the Cairo development list.  I'm more interested in how easy
the API is to use for developers (not wonderful, but its being widely
accepted) and its portability.

Anything that is designed to render to multiple backends can have a new
back-end added.  It wouldn't be much different than the existing
framebuffer backends, and for many graphics cards, it would be
identicle.

> Currently, MiNT doesn't support (ELF) external libraries.

And so I consider any plugin system that isn't supported by the OS to be
a hack.

> You talk again and again since months but what do you wait to add this 
> features into the kernel ?

No one seems to agree that it would even be worth it.  Why would I
bother?  I'm busy with other things.  If no one likes me ideas or
suggestions, I'm not about to spend the time now.  Hell, I can't even
get mint compiled because some of the assembler is still written for the
old GCC 2 format. I'd have to fix that first.

> But what "already written code" do you want to move into the OS?

How about a PNG and SVG output device that work like the memory driver?
How about user defined gradients, non-rectangular clipping rectangles,
and anti-aliased primitives such as squares, circles, and arcs?

> The only usefull functions to add into the VDI is the bitmap->screen 
> convertion, transparency level and zoom functions. And NVDI5 owns this 
> functions since many years.

I'm so glad you can forsee the needs of programmers in the future for
us, and can dictate what is or isn't useful.  We'll just all purchase
NVDI5 for our free OS and be done with it.

> I'm talking about image decompression, not about video or audio format...

I'm not talking about image decompression.  I'm talking about graphics,
ways of putting them on the screen, and ways of manipulating them.

> I provide a little collection of codecs and a library to decode image 
> formats easily ( with one line, you can decode, resize and make the 
> image->screen convertion).  No more no less.

And as people want more advanced capabilities, just "loading an image"
may no longer be sufficient.  I'm not saying zView isn't fine for
loading an image, however, I would definately like to see some standard
API for the plugins that is directly supported by the kernel.