<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - GTK+-3.15.4 dropdown menus don't work on Wayland" href="https://bugzilla.gnome.org/show_bug.cgi?id=743427#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - GTK+-3.15.4 dropdown menus don't work on Wayland" href="https://bugzilla.gnome.org/show_bug.cgi?id=743427">bug 743427</a> from <a href="page.cgi?id=describeuser.html&login=carlosg%40gnome.org" title="Carlos Garnacho <carlosg@gnome.org>"> Carlos Garnacho</a> <pre>From my investigation, the difference stems from weston not triggering the wl_surface_frame() callback, at least during subsurface initialization. At first, _gdk_window_schedule_update() is called on the just created GDK_WINDOW_SUBSURFACE windows, a blank 1x1 buffer is set, and the surface is damaged. The after-paint signal handler in gdkwindow-wayland.c then freezes the frame clock and does wl_surface_commit(). But the frame callback is supposed to thaw the clock, at this point the clock remains frozen, and no further updates can be triggered, so the subsurface remains with the tiny blank surface. This weston behavior is also seen for weston-subsurfaces, although it manages to just keep pushing frames, which happen to get callbacks after the first time.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>