Repaint Issue

[Ander Conselvan de Oliveira]

On 09/11/2012 01:14 PM, Abhijit Potnis 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.

Are you writing your own weston backend?

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 ?
> Is there a way in wayland where in the frequency with which
> "weston_output_repaint
> for idle_repaint" is called, be increased ?

The idea is that the compositor only redraws when necessary. In your 
particular case, a redraw should be scheduled when destroying 
simple-shm's surface. The call path is something like

    destroy_surface()
    weston_surface_unmap()
    weston_surface_schedule_repaint()

This latter function relies on surface->output_mask to schedule the 
repaint only for the outputs the surface is/was in. Can you check if you 
have a valid output_mask?

Cheers,
Ander