XShape example?

[Russell Shaw]

Carsten Haitzler (The Rasterman) wrote:
> On Sat, 29 Oct 2005 17:50:11 +1000 Russell Shaw <rjshaw at netspace.net.au>
> babbled:
> 
> 
>>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
>>data directly.
>>
>>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.
> 
> 
> hell no. i wouldnt bank my app on opengl for that. i'd make an abstraction and
> then slide in whatever engine u want under that to do the actual grunt - from
> software rendering in client-side buffers and then xshmputimage the bastards
> across, to xrender, to opengl, etc.

I've already tried doing drawing programs with client-side rendering.

The scrolling and zooming performance is complete and utter crap, just as slow as
doing all the graphics in gtk.

> opengl is quite "iffy" for 2d - especcially if u want to use textures on pilys
> for replacements of pixmaps - different ogl implementations will round texture
> co-ords diddfernly so u may not end up with precisely the same output on every
> driver - and sometimes the output is less than desireable.

The only way to get snappy zooming and scrolling in a drawing program
is to use OpenGL display lists.