On Tue, Sep 11, 2012 at 5:32 PM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Tue, Sep 11, 2012 at 1:53 PM, Pekka Paalanen <ppaala...@gmail.com> > wrote: > > On Tue, 11 Sep 2012 15:44:55 +0530 > > Abhijit Potnis <abhijitpot...@gmail.com> wrote: > > > >> Hello, > >> > >> Last few days I have been debugging a repaint issue in Weston. No > repaint is > >> triggered until an input event occurs or a Wayland client like > simple-shm > >> triggers > >> one. > >> > >> Digging down, I see that struct weston_output.repaint is pointing to my > >> output repaint > >> function implementation. When I run weston and follow thru the logs, the > >> repaint in > >> my back-end implementation gets called when my > >> 1. mouse moves/or an input event is sensed. > >> 2. when a new client is launched. > >> 3. when a client like simple-shm forces a repaint in a loop > >> > >> The intermittent screen repaints are timed long apart. So the screen > >> doesn't get > >> repainted until any one of the above event happens, which force a > repaint. > >> > >> http://www.youtube.com/watch?v=VGZoFZ9MQX8&feature=youtu.be > >> > >> Here is a video of the behaviour. I launch simple-shm and then kill it > >> (time 0:05), the > >> screen isn't updated until I move my mouse (time 0:11). When I move the > >> mouse the > >> screen is updated and the residual simple-shm disappears from the > screen, > >> which is > >> actually a repaint. > >> > >> Does any body else happen to see such behaviour ? > > > > Yeah, I've seen similar issues on the DRM and X11 backends. When I > > launch an app by clicking a button in the panel, the new window does not > > appear, until something else causes a repaint. Weston-terminal and > > flower, at least. > The repaint problem is only when a client is killed, but not when it is launched. The launch process does behave as expected (as of now :-)) . > > > Repaint is supposed to be as-needed only, not periodical, but clearly > > some trigger is missing. Maybe a new surface is not assigned an output > > until redraw, and redraw does not happen until there is damage, and > > damage is not applied, if the window is not mapped? Or something like > > that, chicken-and-egg problem with assigning an output. A wild guess... > > > Ya, I too feel so. I see that the final weston_output_finish_frame() call after a client is killed arrives with output->repaint_needed set to 0, and hence weston_output_repaint is not called. How does the window unmap-ing process occur ? Is this expected ? > I've seen this for popup surfaces as well. It's fixed by strategically > adding a call to the update transform function which will set the > bounding box, which then will trigger assign_output to work properly. > I have a patch fixing my case that I haven't sent yet and it's > possible that it's the same issue with non-popup surfaces. > Would be good to have :-) > > Jonas > @Ander: Ya, I am writing a GLES2 over fb back-end for a specific board. And I haven't modified any of the client code provided in the Weston repo. The are compiled and run as is. Thanks for the answers. -- Regards, Abhijit Potnis
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
