Hi Fred, I had the same plan as you - Opal will use the existing back/x11 code for window buffers/event handling, so if there are bugs to fix / performance improvements to make in back/x11, they will benefit Opal as well.
Eric On Fri, Jul 9, 2010 at 3:37 PM, Fred Kiefer <fredkie...@gmx.de> wrote: > 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 > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
