Re: FW: [LIBART] ARGB <-> RGBA ?
- From: James Turner <james turner crocodile-clips com>
- To: libart gnome org
- Subject: Re: FW: [LIBART] ARGB <-> RGBA ?
- Date: Fri, 17 Aug 2001 09:41:53 +0100
Hi!
I would like to draw direct to the screen (or direct to a buffer
that is later bitblited to the screen) using libart. Normally
graphiccards support ARGB 32-bit format, but libart can only (?)
generate RBGA. How hard whould it be adjust/extend libart so that
it generated ARGB instead?
I've been working on the Mac port of the new SVG rendering code in
Mozilla (which uses libart as the backend). Macs only support ARGB (in
fact a pad-byte + RGB), so I've had to support this. Also, the design of
the Mozilla X (well GDK) drawing layer is such that a 'native' rendering
mode would give large performance improvements, and permit better
integration with other objects rendered by Mozilla. (ability to use
XGetImage and XPutImage, as I understand it, thougt I'm not an X coder)
Thus, I have been hacking up libArt :-)
I have added a 'pixel format' parameter to art_render_new(), and added
new compositor functions to handle the basic formats I need (RGB, ARGB,
and 555 RGB). The changes work, but need some polish. Thus far I have
been able to ignore the 'clear' and 'solid' render callbacks, because
the SVG code only seems to use the compositor ones.
The pixel format changes only affect the output system; i.e the internal
buffers are always 24-bit RGB. Also all the changes are localised in
art_render.c (and the header). One caveat is that the surface
transformation code (which is a seperate interface) has not been changed.
My worry here is that while my approach clearly works, it's not quite in
keeping with the libArt design philosophy, so I don't know if it an
'acceptable' solution.
If people wish to see my updated versions, please get in touch,.
James Turner
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]