ama@Alliant.COM (Alan Amaral) (01/15/91)
I've been looking at the multibuffering extension in X11R4, in an attempt to port this extension to our hardware implementation of double buffering. In doing so I've uncovered what I believe is a bug in the implementation. In short, it seems that if one draws to the displayed buffer (buffer N) with a particular GC, changes the displayed buffer, then draws again to buffer N with the same GC the results should continue to be drawn onto the screen, NOT into the offscreen pixmap/buffer. This seems like it would happen also if one draws into a non-displayed buffer, makes this buffer the displayed buffer, then again draws into the same buffer with the same GC, the results will continue to go into the pixmap, NOT the window. If you look at the VALIDATE_DRAWABLE_AND_GC macro it does some caching of the last used drawable and GC resource id mappings in the client data structure in an attempt at minimizing the number of resource lookups that need to be performed. Unfortunately, the multibuffering extension CHANGES the resource mapping when it aliases the buffers to/from the actual window, and it doesn't seem to do anything that would cause the mapping in the client data structure to be changed. It seems like the simple fix is to set client->lastDrawableID to INVALID in ProcDisplayImageBuffers when this resource id matches one that is about to be aliased. Of course this only works for the client actually doing the DisplayImageBuffers request. The only sure fixes that I can see would be to either remove the GC caching from the system (but that would slow things down considerably), or else add code to further qualify the drawable id mapping depending upon whether the drawable is double buffered or not. The latter is the one I'll persue when I verify that is actually a bug. Has anyone noticed this problem? I haven't actually seen this bug exhibited with any clients, but there are not that many that use this extension, and apparently none that do things this way. I'll eventually get around to writing a test case, but I wanted to know if anyone else has seen/fixed it yet. aTdHvAaNnKcSe us mail: Alliant Computer Systems uucp: aamaral@elmo.Alliant.COM One Monarch Drive phone: (508) 486-4841 Littleton, MA 01460 -- us mail: Alliant Computer Systems uucp: aamaral@elmo.Alliant.COM One Monarch Drive phone: (508) 486-4841 Littleton, MA 01460