[PATCH 3/3] exa: properly wrap Create/DestroyPixmap in ExaCheckPolyArc and fix GC (un)wrapping.

[Maarten Maathuis]

2009/11/12 Michel Dänzer <michel at daenzer.net>:
> 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
>