<div class="gmail_quote">On Tue, Aug 14, 2012 at 8:09 AM, Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com" target="_blank">hoegsberg@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Tue, Aug 14, 2012 at 03:51:40AM -0600, Scott Moreau wrote: > This fixes a bug exposed by 982387011ff where tooltips were not drawn while > the compositor is idle until the next output repaint. > --- > > Just schedule a repaint instead of preemptively calling weston_surface_update_transform(). </div>This isn't right either. We don't want to schedule a full repaint whenever we go through weston_surface_assign_output(). I think when we started using weston_surface_schedule_repaint() instead of weston_compositor_schedule_repaint() in a few places, we changed weston_surface_damage() to not schedule repaints when the surface isn't visible. So the bug is that there are still a few places that rely on that behaviour and we need to fix those to call weston_compositor_schedule_repaint() instead of weston_surface_damage(). I was thinking that shell.c map() was guilty of that, but it does call assign output, and the client then later calls wl_surface.damage, which calls weston_surface_damage(), which (with an output now assigned) will schedule the repaint. Not sure.. Kristian </blockquote><div> I'm not sure what you want to do then. Calling a 'full repaint' doesn't actually damage the entire screen, it only damages what intersects with what is actually damaged. You can see this with the useful damage debug patch. The real problem is that the transform region is empty when assign output is called. The resulting bug is a problem that many have noticed and needs attention. However I'm done looking into it. So to recap, this patch <a href="http://cgit.freedesktop.org/wayland/weston/commit/?id=982387011ff5cf654a49c835a86bf0e52675733b">http://cgit.freedesktop.org/wayland/weston/commit/?id=982387011ff5cf654a49c835a86bf0e52675733b</a> exposes the bug and this is the explanation I came up with after debugging <a href="http://lists.freedesktop.org/archives/wayland-devel/2012-August/004859.html">http://lists.freedesktop.org/archives/wayland-devel/2012-August/004859.html</a> Scott </div></div>