On 05/13/2015 11:34 PM, Jonas Ådahl wrote:
Okay, looking at the clickdot and resizor examples, it appears you are
actually responding to events with pointer_lock. This is pretty much
what I think makes sense but your notes were very misleading.
The primary problem is that you removed the serial of the triggering
event, which is VITAL for this to work. You have to put that back. The
compositor has to know what event caused the lock!
I am still fully mystified as to the purpose of the "region" in the
request. I think the purpose of this could be handled by the client
sending the request only when the mouse enters the region. However it is
possible you intend to use the "region" as part of the compositor
interaction, maybe it wants to highlight it, or place a dialog box
centered in it.
Also very confusing is the purpose of the "locked" event. I think the
idea is that if there is compositor interaction with the user before the
lock happens, then the locked event is delayed. But in normal use the
locked event happens immediately?
Both of these questions could be clarified with a sketch showing the
"compositor interaction before the lock" that you are proposing.
Why and how would a client send a widget layout?
Because the window was resized!
- The client must hide the cursor and draw a fake one. This will blink as
there is no synchronization between changing the cursor image and mapping
another surface. And it means that the client cannot take advantage of any
hardware acceleration the compositor applies to the cursor. Toolkits have to
implement two different methods of changing the cursor image, too.
If the client controls the pointer position, it'll instead be a delay
between the widget and the pointer (as there is no synchronization
between them), the pointer cursor will lag when the client is slow, and
the there will be an added latency compared to the normal use case. I
don't think its really better to allow the client to move the pointer
cursor. If a client wants to avoid a "blink", it can improve the
situation by scheduling the set_cursor and commit intelligently. I don't
think adding latency lag to pointer cursors is a good enough reason to
support slow-scroll-bar-with-lagging-cursor use case.
The delay you are describing is a DESIRABLE FEATURE. I need the cursor
to be locked precisely to the graphic it is dragging. Jiggling around is
NOT wanted and is the entire reason I am proposing this. Other than
games this is the entire reason anybody is interested in pointer lock.
The blink is not avoidable because cursors are not 100% opaque. This
means that the compositor can only draw one image of the two cursors, it
cannot composite two atop each other, or there will be a visible defect.
I suppose a lot more commit sync rules could be added but it seems an
awful lot easier to just reuse the existing ability to change the
cursor! I also suspect that the real cursor will have better hardware
acceleration than the fake one.
I don't understand why you don't want to allow the client to move the
cursor, yet you seem fine with them hiding it and drawing a fake one,
which requires far more api and overhead and latency.
All I can guess is that you think moving the pointer will change the
mouse events. That is wrong, I want it to work exactly like your "hint":
it has no effect on mouse x/y events until after the lock ends. The only
difference is that the cursor is always drawn at the current "hint"
position. If the cursor is invisible this is EXACTLY 100% IDENTICAL to
your proposal!!!
PS: do not "warp the pointer to the region on lock". This is ABSOLUTELY
not wanted under any scheme, either yours or mine.
- The lock_pointer request is sent in response to a triggering event, such
as a mouse-down inside the region. It does not have a region argument, but
does have an event serial so the compositor can identify the triggering
event. The compositor can then decide to grant or refuse the lock, or even
popup some user interface to allow the user to choose.
This way a client cannot lock 'by default'. For example you might want
to start a game and the lock should work. Right now, since we have the
click-to-activate-allows-lock policy it won't work, but that is just a
policy that is easily changed.
I can't imagine any scheme where the policy makes any difference until
the client requests a lock.
Then how do you lock without an event? Busy-loop? Try on every pointer
enter?
Try on every pointer enter and on mouse clicks.
The point of confine regions is that a client can confine a pointer to a
region without having to introduce extra latency to the pointer cursor.
If a client wants regions more complicated than wl_region, or be in
total control of speed etc, it will probably have to live with the
latency though.
Okay that sort of explains your reason for confine.
However I have a much simpler idea: have the position-the-cursor request
take a rectangle, not just an xy. The cursor is then confined to this
rectangle. A zero-sized rectangle reproduces the original idea.
Your design lacks the ability to change the confine region, which is
needed if the game is resized. The above request solves that problem.
It also allows complex confine regions with less (but not zero) latency.
The client just sends the largest rectangle that is inside the confine
region and contains the current pointer position, and only updates this
when it changes.
Even if lock_pointer and confine_pointer are different requests, they
really should return the same object using the same events. The current
design just doubles the size of all the wayland protocol api for no
useful reason, the client knows exactly which request was used to create
the object.
- (Maybe) Add an argument to lock_pointer to reuse the normal grab machinery
such that release of all the mouse buttons will automatically cancel the
lock. The reason for this is to avoid round trips by reusing code that is in
the compositor anyway.
A client can just unlock on release. See the resize example how this
already works. I dont see a point adding extra protocol for something so
trivial.
The reason is that your "compositor interaction to enable the lock" may
want to be considerably different if it knows the lock will be lost if
all the buttons are released. If requested for a mouse-down event then
this is no more harmful that the normal automatic grab so it probably
should be granted without question.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
