nanogui@linuxhacker.org

Hello!

(Sorry if this mail is a duplicate, first mailing failed
somewhere along the line yesterday localtime).

I've been thinking about how to best arrange for stuff like
optimizations etc. during my effort to speed up and improve
the GdArea function, and I've got a few notes I'd like to
share in this respect and a list of stuff I want to implement..

Please note that currently, the GdArea/GrArea functions are
very important to us and Opera, and may be even more so if
Vidar decides to use GdArea in his efforts to beat X11 in
the font rendering game...  Which I'm prepared to help him
with of course:-)  Which means I'll make GrArea fast and
flexible, or use other means like Blit if this is considered
better.  I'm worried the Blit function may end up being too
flexible, large, and hard to optimize, though.  Anyways;

I have a wish-list I'm prepared to implement:

1) Tiling of images.  Painting a non-uniform background
   can be done with tiles, which would reduce the client
   to server overhead a lot (e.g. only transfer the
   single smaller image).  I envision this to be a feature
   of GrArea.

2) It should be possible to do sub-imageing on the client
   side by GrArea without temporary storage, e.g. the
   application wants to take a small piece out of a larger
   image and paint it on the screen.  This could be relevant
   when repainting only parts of a large image for example.
   By having the client side extract only the pixles needed,
   the transfer is more efficient.

3) Alpha blending.  Yeah.  It's definite, I've gone mad.
   Actually it could be really nice to do true alpha
   blending in the server.  Some of the stuff our designers
   have come up with could use some alpha blending to
   avoid having the entire user interface as a single image..

   Alpha blending would also be great news to the anti-
   aliased font support by Vidar... We could have true
   anti aliasing against a textured background this way....

   Not something for the faint of heart, or 286 projects,
   but it would make Nano-X rock as a high quality
   environment.

I'm not sure where this should be done, though.  It probably
belongs in the Blit function, which would grow large, but
I have a concern for the Blit function:

Is it future-proof to require the destination 'psd' to do the
operation?  What if the source 'psd' is better suited for the
job?  I'm probably thinking device-device bliting where none
of the devices are memory, which is probably not supported yet,
just thinking of the future when PDAs and stuff will have like,
err, stereo views or something?

I have extended the existing code with a psd->DrawArea function,
with a couple of emulation functions, and it seems to work like
a charm.  Should I continue this or try to integrate with Blit?
Changing the low level part to Blit later on should be easy, but
we may better experiment and figure out what is needed when they
are separate. Comments?

I'll get back on the pre4, it has some problems with the make
system, foremost: SCREEN_PIXTYPE is not defined for all the
compiler runs where it is needed.

Thanx for the effort to all of you!

So long,
Morten Rolland