Repaint Issue

[Abhijit Potnis]

Hello Jonas,

Thanks, I tried the patch. Does not solve my problem!

On Tue, Sep 11, 2012 at 8:24 PM, Jonas Ådahl <jadahl at gmail.com> wrote:

> 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>
> >> wrote:
> >> > 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
> > 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 :-)
>
> 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:
>
> http://lists.freedesktop.org/archives/wayland-devel/2012-September/005330.html
>
> Jonas
>



-- 
Regards,
Abhijit Potnis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120911/a9ca34a1/attachment-0001.html>