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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
