[Xcb] XCB/GLX and resizing windows leads to incorrectly places GLX contents

Ruben Van Boxem vanboxem.ruben at gmail.com
Sat Jul 14 18:45:56 UTC 2018

Hello list,

I have set up a limited drawing and windowing framework and am able to draw
into a window using Skia by just blitting the produced image to screen
using xcb_put_image.
My event loop is set up to draw on Expose events, and I retrieve the actual
window geometry from xcb before drawing.

If I exchange this to OpenGL, and let Skia draw directly on screen, I get
into trouble when resizing my window.
The best I can do to describe this behaviour is that it seems as if the GL
content is not drawn at the correct position. If I remember correctly, a
similar effect ("accelerated" offset positions for window content) happened
if I would redraw on a ConfigureNotify event with the geometry of that

It seems to resemble this bug:
Only difference is that I seem to be running on DRI3, and I do not get any
unknown events unless I set the environment variable
LIBGL_DRI3_DISABLE=true. Then the observed behaviour becomes much worse,
and I receive unknown events. I would guess that the workaround described
in the above bug report would work to fix that DRI2 issue.

Then remains the issue in DRI3 mode: I am not getting any unknown events
whatsoever, and can't find anything that would give me enough information
to actually fix this incorrect positioning of window content.

The relevant source code is here:
event handling:
xcb window (created through a connection from an Xlib Display for GLX):
glx setup:

The whole thing is quite a complicated setup as I want to handle several
types of windowing and graphics backends and this manner of split was the
natural result I came up with for now.
If you want to compile the code, you'll need 10-15 minutes, a recent C++
compiler and CMake. The executable in question is

So to summarize: I see Bug 35945 and could probably handle that, but I also
see a less drastic but similar GLX/XCB problem when DRI3 is used in which
case the XESetEvent workaround will definitely not work. I do not see this
issue if I render to screen in pure xcb (no xlib/glx involved). I have no
idea what I can do to resolve this issue.
A movie of the effect is here:
XCB/CPU: https://www.dropbox.com/s/oxj06vbr8k6fvay/xcb_put_image.mp4?dl=0
The DRI2 movie is with LIBGL_DRI3_DISABLE=true, making the effect a lot

Thanks for any help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xcb/attachments/20180714/a3e1d9ad/attachment.html>

More information about the Xcb mailing list