Repaint Issue

Ander Conselvan de Oliveira conselvan2 at
Tue Sep 11 04:36:19 PDT 2012

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.
> 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


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?


More information about the wayland-devel mailing list