<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2018-07-14 20:45 GMT+02:00 Ruben Van Boxem <span dir="ltr"><<a href="mailto:vanboxem.ruben@gmail.com" target="_blank">vanboxem.ruben@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello list,</div><div><br></div><div>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.<div></div><div>My event loop is set up to draw on Expose events, and I retrieve the actual window geometry from xcb before drawing.</div><div><br></div></div><div>If I exchange this to OpenGL, and let Skia draw directly on screen, I get into trouble when resizing my window.</div><div>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.<br></div><div><br></div><div>It seems to resemble this bug: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=35945" target="_blank">https://bugs.freedesktop.org/<wbr>show_bug.cgi?id=35945</a></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The relevant source code is here:</div><div>event handling: <a href="https://github.com/skui-org/skui/blob/master/gui/events/xcb.c%2B%2B" target="_blank">https://github.com/skui-org/<wbr>skui/blob/master/gui/events/<wbr>xcb.c%2B%2B</a></div><div>xcb window (created through a connection from an Xlib Display for GLX): <a href="https://github.com/skui-org/skui/blob/master/gui/native_window/xcb.c%2B%2B" target="_blank">https://github.com/skui-org/<wbr>skui/blob/master/gui/native_<wbr>window/xcb.c%2B%2B</a></div><div>glx setup: <a href="https://github.com/skui-org/skui/blob/master/gui/native_visual/glx.c%2B%2B" target="_blank">https://github.com/skui-org/<wbr>skui/blob/master/gui/native_<wbr>visual/glx.c%2B%2B</a></div><div><br></div><div>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.</div><div>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/<wbr>widget_gallery".<br></div><div><br></div><div>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.<br></div><div>A movie of the effect is here:</div><div>DRI3: <a href="https://www.dropbox.com/s/obkdzd2j67zl5yy/glx_context_resize_dri3.mp4?dl=0" target="_blank">https://www.dropbox.com/s/<wbr>obkdzd2j67zl5yy/glx_context_<wbr>resize_dri3.mp4?dl=0</a></div><div>DRI2: <a href="https://www.dropbox.com/s/my8gg3rfcab45fg/glx_concext_resize_dri2.mp4?dl=0" target="_blank">https://www.dropbox.com/s/<wbr>my8gg3rfcab45fg/glx_concext_<wbr>resize_dri2.mp4?dl=0</a></div><div>XCB/CPU: <a href="https://www.dropbox.com/s/oxj06vbr8k6fvay/xcb_put_image.mp4?dl=0" target="_blank">https://www.dropbox.com/s/<wbr>oxj06vbr8k6fvay/xcb_put_image.<wbr>mp4?dl=0</a><br></div><div>The DRI2 movie is with LIBGL_DRI3_DISABLE=true, making the effect a lot worse.</div><div><br></div><div>Thanks for any help!<br></div></div></blockquote><div><br></div><div><div>Hi everyone,</div><div><br></div><div>sorry to be that guy who asks his question and immediately after sending it to the world, finds a solution:</div><div>It appears that this sequence:</div><div>glXSwapBuffers(display, drawable);<br>glClear(GL_COLOR_BUFFER_BIT);</div><div><br></div><div>does not work and actually causes the issue I tried to describe in detail in my previous email.</div><div>Removing the glClear makes the problem go away.</div><div><br></div><div>Unfortunately I'm not so experienced with OpenGL so I have no idea why this actually causes/fixes the issue.</div><div><br></div><div>Ruben<br></div> </div></div><br></div></div>