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

<span class="HOEnZb"><font color="#888888"><br>
Jonas<br>
</font></span></blockquote></div><br>@Ander: Ya, I am writing a GLES2 over fb back-end for a specific board. And <br>I haven't modified any of the client code provided in the Weston repo. The are<br>compiled and run as is.<br clear="all">
<br>Thanks for the answers.<br><br>-- <br>Regards,<br>Abhijit Potnis<br><br>