Re: cario and shmget problems

[Fred Kiefer]

Am 09.07.2010 12:10, schrieb David Chisnall:
> In fact, the use of shared memory with the Cairo back end is
> currently completely wrong - it may work, but it's a design that will
> give absolutely the worst possible performance possible from Cairo,
> because we're implicitly telling Cairo not to use hardware
> acceleration for drawing and then telling the X server to perform a
> redundant copy if it wants to do hardware acceleration.  This is
> something that Opal will fix by not trying to make Cairo look like
> libart, so I'm not sure if it's worth bothering chasing a short-term
> fix.

David,

could you please elaborate a bit more how the way Eric is implementing
Opal will be different in the way it handles window memory? Up to now I
had expected that Opal would leave all the window (and event) management
to the existing code and only provide a slightly different way to
package up the drawing code. The current code structure isn't actually
modelled after libart, it is based on the PostScript drawing structure
GNUstep inherited from OpenStep.

As far as I remember the usage of XWindowBuffer via the
XGCairoXImageSurface was added to allow the usage of 32 bits to have
transparency handling even when the graphic card didn't support it
(Which was the normal case at that time). This may be obsolete now for
most modern graphic cards, but if there is an easy way to change this,
doing so in back wont be any harden than doing it just in Opal.

Or am I completely missing something here?
Fred