Re: Drawing your own pointer in Wayland

Am 2018-12-18 11:33, schrieb Philipp Kerling:

> So what I guess I'm missing is a concrete example of what sort of
> erratic behavior I can expect with the current setup (that does not use
> pointer constraining and relative motion) and how the two protocols
> improve that situation. In practice I did not notice any wrong/strange
> behavior yet, but I know that this does not mean much. Martin Flöser
> mentioned pointer warping as an issue, but to be honest I did not
> completely understand under which circumstances this would become
> problematic.
> 
> I'm hoping someone can shed a bit more light on this.

Hi Philipp,

well you already mentioned the main problem: input lag. The mouse cursor 
position will never be correct, especially when fast moving and 
clicking.

With a normal setup the cursor image position updates on the next page 
flip. In your setup the cursor image position updates the next time kodi 
has rendered and KWin has rendered. The normal way guarantees that the 
cursor is at the correct position in max 1 frame (next page flip). In 
your setup it's more likely to be 2 frames at least. We have at least 
two roundtrips from wayland compositor to client (update position 
followed by damage of surface) and then rendering of the complete scene. 
So for fast movement the cursor lags behind.

The second problem as I mentioned in the bug report is cursor warping. 
KWin warps the cursor, that happens for example when approaching a 
screen edge - the cursor is rapidly pushed back. This is a rather fast 
movement and cursor update sequence. This is something where I fear a 
client could just not keep up with updating. Well keeping updating is a 
problem anywhere. Consider a fast movement - you get possible hundreds 
of pointer position updates per frame interval. And you have to render 
the right position. In KWin's mouse cursor emulation path we render the 
position where the mouse is at the time of the rendering. But you don't 
have that much control, you still have to damage and commit the surface.

The idea behind pointer locking is to solve this problem. You get 
control over the mouse cursor, the compositor doesn't update at all. So 
the cursor cannot lag. Instead of getting absolute events, you use 
relative events and position the cursor based on that. It also allows 
you to warp the cursor - if you need to.

So for me this is a very simple thing: we do not want to support your 
approach as there is a proper protocol to support it. And I think your 
users would prefer that there is no input lag, too.

Cheers
Martin