2009/11/12 Michel Dänzer <[email protected]>: > On Sat, 2009-11-07 at 13:32 +0100, Maarten Maathuis wrote: >> - Fix the system that is required for it to actually work. >> - The comment near the new macros explains the problem that existed before. > > I'm not sure it really explains why we need two levels of wrapping.
The 2nd level is needed is because you want to do something more than usual wrapping. The DestroyPixmap example is a nice one. If i use single wrapping i loose fbDestroyPixmap which is unacceptable, because the chain has to be like this: exaDestroyPixmapWithFinish->damageDestroyPixmap->exaDestroyPixmap->(w)fbDestroyPixmap, with single wrapping this would be exaDestroyPixmapWithFinish->damageDestroyPixmap->exaDestroyPixmap->exaDestroyPixmapWithFinish, which is a loop. An alternative idea would be to put fallback checks/flags in all acceleration functions, createpixmap, etc and do the right thing there. And stop unwrapping gc ops altogether. > >> - Why it didn't cause issues before i don't know. >> - We cannot unwrap the GC funcs, because they do prepare/finish access too. >> - Protect against setting CreatePixmap twice (which would break swapping) in >> GC >> functions. > > Would it be feasible to make a general - not specific to PolyArc - > solution, in case other fb hooks use / start using temporary pixmaps? Yes, it can be extended, and as long as it concerns scratch pixmaps it should be fine. It could even be made specific just for scratch pixmaps. > > > -- > Earthling Michel Dänzer | http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
