I don't see any explanation what the serious issue in
exaChangeWindowAttributes was.
P.S. Why haven't you pushed the changes I acked?
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
On Tue, Mar 3, 2009 at 9:12 AM, Michel Dänzer mic...@daenzer.net wrote:
I don't see any explanation what the serious issue in
exaChangeWindowAttributes was.
fbChangeWindowAttributes can cause a switch of pixmap (much like
fbValidateGC), so you need to trap Destroy and Create pixmap, in order
On Tue, Mar 3, 2009 at 5:15 AM, Maarten Maathuis madman2...@gmail.com wrote:
On Tue, Mar 3, 2009 at 9:12 AM, Michel Dänzer mic...@daenzer.net wrote:
I don't see any explanation what the serious issue in
exaChangeWindowAttributes was.
fbChangeWindowAttributes can cause a switch of pixmap
It would be really nice if you would put information like this in your
commit messages so that people looking at the history can determine
the reason for the commit.
After Michel's question i updated the commit message to contain more
information. A few updated patches will be posted shortly.
- fbChangeWindowAttributes can create pixmaps (and access them) without use
preparing access.
- Also handle the destroyed pixmaps by finishing them first.
- Switch to DEST indices again in exaCreatePixmapWithPrepare, because they are
obviously being rendered to.
- Also avoid calling FinishAccess
