jadahl at gmail.com
Tue Sep 11 07:54:50 PDT 2012
On Tue, Sep 11, 2012 at 4:48 PM, Abhijit Potnis <abhijitpotnis at gmail.com> wrote:
> On Tue, Sep 11, 2012 at 5:32 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
>> On Tue, Sep 11, 2012 at 1:53 PM, Pekka Paalanen <ppaalanen at gmail.com>
>> > On Tue, 11 Sep 2012 15:44:55 +0530
>> > Abhijit Potnis <abhijitpotnis at 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
> 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
> 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 :-)
You can try the patch Ander just posted which solves the same problem
by calling the update transform function every time a surface gets an
output assigned before the bounding box has been set. See here:
More information about the wayland-devel