Re: [MiNT] Cool new AES features

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Tue, 2005-07-05 at 17:11 -0400, Mark Duckworth wrote:
> Exploitation of truecolor graphics in a similar way to xgem with
> gradients and such.

Good consistent gradients are a major issue especially when you want to
take into consideration things like number of colors available and
reduce the chance of seeing "bars" of color.  For example, a very large
gradient (screen width) through a narrow band of color will often show
banding if not dithered.  This was an issue in older versions of Gimp,
and is now "fixed".

VDI just doesn't have any support for gradients at all.  So, new
graphics calls are needed there, especially if you want any chance of
acceleration or device independance.

> Themes - theme change on the fly is not necessary to me if too
> difficult, or if some apps do not respond properly, no big deal - as
> long as there's no crashing

I'll leave this one alone.

> Truecolor desktop backgrounds in many image formats doing whatever
> conversions necessary via zview.

I don't know if zview is the right idea.  There are lots of graphics
libraries capable of manipulating a huge number of file formats and
doing smooth resizing.  I'd prefer the OS to support it so that there is
a better chance of hardware acceleration in the future and less
redundant code in the applications.

> Desktop background manager applet and perhaps some calls to change it
> and lastly truecolor icons.

A desktop background should be as simple as having the desktop support
it.  Make the background a userdef object and let the desktop paint it.
Although I suppose other programs that paint there own desktops would
interfere.

As for icons, true color icons likely means another icon format. This
would have to be discussed depending on what features you want.

Do you also want these icons to be resizable smoothly (such as SVG
icons, which would honestly be a bit slow), or anti-aliased to any
background using alpha-channel compositing like you would get with PNG
icons (PNG support RGBA for antialiasing - I do it a lot with web
pages).  This makes smooth drop-shadows and anti-aliased edges easy.

> These are most important to me.  I know AES is only responsible for part
> of it, but all you really have to do is look to other windowing systems
> to see what users desire.

In this case, I think what you are asking for is a more powerful
graphics library.  VDI is kinda aging.  Do you want to add functions to
it, or just replace it totally?  The EVAS project from Enlightenment and
Cairo (soon to be the new standard backend for graphics on Linux) are
both good candidates.  EVAS has better performance when not accelerated
since Cairo is still developing, however, Cairo is getting way more
support, and it renders to multiple backends (not just the screen)
including postscript, pdf, bitmaps, and SVG, much like the VDI supports
multiple output devices.  

Cairo and EVAS will also render directly to OpenGL for hardware
acceleration, which isn't as impossible on the Atari as you may think.
Already, Aranym can convert VDI calls to host-OpenGL, and there are
open-source drivers for a number of cards, including the ATI (up to R200
chipsets, meaning the 9200SE and below).

So - add new VDI calls, or make the old VDI a wrapper around a new
library with the features you want already done, such as Cairo?

> Some sort of urgent api for taskbar such that I could cause it to flash
> when a new message was received in gim would be ultra-cool.

This wouldn't require an AES update - just a set of standards for
communication.