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

[Michel Dänzer]

On 2018-07-14 08:55 PM, Ruben Van Boxem wrote:
> 2018-07-14 20:45 GMT+02:00 Ruben Van Boxem <vanboxem.ruben at gmail.com>:
> 
>> 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
>> event.
>>
>> It seems to resemble this bug: https://bugs.freedesktop.org/
>> show_bug.cgi?id=35945
>> 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: https://github.com/skui-org/skui/blob/master/gui/events/
>> xcb.c%2B%2B
>> xcb window (created through a connection from an Xlib Display for GLX):
>> https://github.com/skui-org/skui/blob/master/gui/native_window/xcb.c%2B%2B
>> glx setup: https://github.com/skui-org/skui/blob/master/gui/native_
>> visual/glx.c%2B%2B
>>
>> 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 "examples/widget_gallery/
>> widget_gallery".
>>
>> 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:
>> DRI3: https://www.dropbox.com/s/obkdzd2j67zl5yy/glx_context_
>> resize_dri3.mp4?dl=0
>> DRI2: https://www.dropbox.com/s/my8gg3rfcab45fg/glx_concext_
>> resize_dri2.mp4?dl=0
>> 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
>> worse.
>>
>> Thanks for any help!
>>
> 
> Hi everyone,
> 
> sorry to be that guy who asks his question and immediately after sending it
> to the world, finds a solution:
> It appears that this sequence:
> glXSwapBuffers(display, drawable);
> glClear(GL_COLOR_BUFFER_BIT);
> 
> does not work and actually causes the issue I tried to describe in detail
> in my previous email.
> Removing the glClear makes the problem go away.

When the window size has changed, do you call glViewport et al between
glXSwapBuffers and glClear?

Which version of Mesa are you testing with?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer