http://bugzilla.suse.com/show_bug.cgi?id=1097207 http://bugzilla.suse.com/show_bug.cgi?id=1097207#c1 Stefan Dirsch <sndirsch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt@suse.com Flags| |needinfo?(fvogt@suse.com) --- Comment #1 from Stefan Dirsch <sndirsch@suse.com> --- Hmm. In which package can I find qmlscene? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1097207 http://bugzilla.suse.com/show_bug.cgi?id=1097207#c3 --- Comment #3 from Stefan Dirsch <sndirsch@suse.com> --- Ok. Which desktop? How configured, i.e. with/without Compositor, etc. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1097207 http://bugzilla.suse.com/show_bug.cgi?id=1097207#c5 --- Comment #5 from Fabian Vogt <fvogt@suse.com> --- Just tried with icewm, same behaviour. Broken with llvmpipe, works with nouveau. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1097207 http://bugzilla.suse.com/show_bug.cgi?id=1097207#c7 Michal Srb <msrb@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS Assignee|xorg-maintainer-bugs@forge. |msrb@suse.com |provo.novell.com | --- Comment #7 from Michal Srb <msrb@suse.com> --- More observations: It also happens in Wayland, both Plasma and Gnome. (With nouveau.) But on X it can be prevented by setting LIBGL_DRI3_DISABLE=1. Qt re-renders the window after it receives the expose event. It seems that at that moment the main framebuffer still has the previous size. So after maximizing the rendering goes into buffer that is too small and does not cover the window. After restoring back to the 200x200 size, the rendering draws into 200x200 rectangle in left bottom corner of the framebuffer, but the window then displays 200x200 rectangle from the left top corner which contains just white color. The main framebuffer seem to be resized after the rendering is done. I am still trying to find why. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1097207 http://bugzilla.suse.com/show_bug.cgi?id=1097207#c9 --- Comment #9 from Michal Srb <msrb@suse.com> --- Dumping what I debugged so far: When the window is maximized or restored, Qt renders everything twice: * As reaction to the Expose event, followed by glXSwapBuffers. * As reaction to some QTimer event, NOT followed by glXSwapBuffers! When using DRI2, Mesa reacts to the DRI2_InvalidateBuffers X11 event as soon as it is received and resizes the framebuffer at the beginning of next OpenGL call. When using DRI3, Mesa waits for first OpenGL call after glXSwapBuffers, then it retrieves events and if there was PresentConfigureNotify, it resizes the framebuffer. So the difference is that DRI2 is willing to resize the framebuffer at any point, DRI3 waits for the buffer swap. I have searched whether it is intentional and so far I have the impression that it is, although I did not find it anywhere explicitly stated. So this is what happens when maximizing and restoring the qmlscene window: * Start: window is small, framebuffer is small * Maximize clicked * PresentConfigureNotify delivered (queued in xcb) * Expose delivered - Qt will redraw, Mesa retrieves the event during the first OpenGL call and resizes the framebuffer -> Qt draws properly into the big framebuffer * Qt calls glXSwapBuffers -> the big framebuffer is delivered to the big window * QTimer event - Qt will draw again, but does not call glXSwapBuffers! -> nothing is delivered to the window * Restore clicked * PresentConfigureNotify delivered (queued in xcb) * Expose delivered - Qt will redraw, since there was no glXSwapBuffers, it is still drawing the "same" frame and the framebuffer is not resized. -> Qt draws small red rectangle into big framebuffer. * Qt calls glXSwapBuffers -> the big framebuffer is delivered to the small window, we see the wrong part of it which was cleared white * QTimer event -> Qt will draw again. This is the first OpenGL call after a swap, so the framebuffer is resized to the small size. -> Qt draws properly into the small framebuffer * No glXSwapBuffers is called! -> nothing is delivered to the window If you maximize & restore repeatedly the issue continues because the missing swap keeps the framebuffer resize delayed. If any other update repaints the window, it gets fixed until the next maximize & restore (or restore & maximize). I have not yet investigated why Qt repaints twice and why it does not call glXSwapBuffers the second time. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1097207 Stefan Dirsch <sndirsch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|msrb@suse.com |xorg-maintainer-bugs@forge. | |provo.novell.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1097207 http://bugzilla.suse.com/show_bug.cgi?id=1097207#c13 Stefan Dirsch <sndirsch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |NORESPONSE --- Comment #13 from Stefan Dirsch <sndirsch@suse.com> --- Still waiting for a response for more than a month now. Please reopen once you can provide the requested feedback. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1097207 http://bugzilla.suse.com/show_bug.cgi?id=1097207#c15 --- Comment #15 from Stefan Dirsch <sndirsch@suse.com> --- Ok. Thanks for feedback! -- You are receiving this mail because: You are on the CC list for the bug.