rjshaw at netspace.net.au
Sat Oct 29 00:50:11 PDT 2005
Matt Garman wrote:
> On Sat, Oct 29, 2005 at 01:38:59PM +0900, Carsten Haitzler wrote:
>>On Fri, 28 Oct 2005 23:20:17 -0500 Matt Garman
>><garman at raw-sewage.net> babbled:
>>>eyes looks as though it's transparent). [BTW, I know it's not true
>>>transparency, but as long as it *looks* transparent, that's good
>>>enough for me.]
>>it is true transparency. no pixels exist in the "shaped out" areas
>>- you see right through it - events go through the holes too. its
>>the oldes form of transparency x has - but effectively only
>>provides 1 bit of accuracy :) (i wont go into how its implemented
>>with rectangle lists) :)
> Ahh, now that I have a working example, I see that it is in fact
> true transparency.
> When you say that this is the "oldest form of transparency x has",
> does that imply there are *better* ways of doing transparency?
> As a general disclaimer, I'm just getting into Xlib programming, so
> it's safe to assume total ignorance on my part!
You should get the Xlib Programming Manual, Xlib Reference Manual,
and others in the set if interesting. ISBN: 1-56592-002-3
It explains all about colour-planes.
With core X, to blend colours in a mathematically linear way as you'd
expect, you'd need to read the image from the server, do your own blending
with a separate alpha-channel image, then write it back to the server, which
makes for very slow performance.
There's X extensions (Render extension IIRC) that accepts alpha-channel
I've been tempted to add alpha-channel colours to a bunch of the X core
functions, but with slightly different names and as an extension.
However, i can't think why anyone needs it. If you're making a drawing
program, you should use core X to do the GUI graphics, and OpenGL to
do the actual drawing-widget contents.
More information about the xorg