On 04/24/2015 08:51 PM, x414e54 wrote:
On Fri, Apr 24, 2015 at 6:22 PM, Pekka Paalanen <[email protected]> wrote:
Then apps would need to know what the accel paramaters mean, which
requires us to lock down the acceleration logic and mathematical
functions in the protocol specification. I don't think that is
something Wayland wants to specify.
I intended acceleration would just be a bool on/off.
As a practical matter the applications that want a slow scrollbar want
*exactly* the same acceleration as before, just that the resulting position
is scaled down. Forcing them to replicate the code that the compositor is
doing seem mistaken.
Speed would be as a scale/percent and does not effect acceleration.
You could call it whatever, "movement scale", etc, so this should be
acceptable?
I believe we are both questioning the idea that you use the raw device
api to "grab" the mouse, as this would apparently bypass the
acceleration code. It sounds like you are proposing keeping the
acceleration result somehow accessable.
A boolean acceleration on/off will not work because it is asynchronous.
Both the accelerated and unaccelerated positions must be available
directly as events (though it is ok if you don't get the unaccelerated
ones until you turn on grab and it then replays any missing ones since
the grabbing event.
On Sat, Apr 25, 2015 at 5:06 AM, Bill Spitzak <[email protected]> wrote:
That is not sufficient as the application may want to put much more complex
rules on how the pointer moves (such as limiting it to a rectangle).
Limiting to a specific rectangle is slightly different as you cannot
do that by warping a cursor.
Sure you can. Clamp the x and y to be inside the rectangle and warp the
cursor to that position.
Possibly you are thinking that the warped cursor position somehow
effects the events? That may explain why the really simple api I am
proposing seems to be confusing people.
What I want when a grab happens is the events continue UNCHANGED. You
get exactly the same events including xy and relative motion, no matter
how you move the cursor around. The cursor image is completely unrelated
to the position being used to produce events.
If you could change the cursor to drag including the scrollbar and
then confine the cursor to an area, also including the speed settings
this should allow the compositor todo everything.
Something like all in one api call:
wl_pointer::start_drag
serial
uint - serial of the implicit grab on the origin
surface
wl_surface - image to drag under the cursor
speed
fixed_t - movement scale
acceleration
enum - turn acceleration on off for this drag.
confinement_region
wl_region - cursor movement region within the draggable surface
(allows null)
drag_region
wl_region - movement region of the draggable surface (allows null)
That is vastly too complicated. In particular it requires the client to
draw the scrollbar slider using a subwindow, thus making support of this
go deep into the low level drawing routines of the client, which is
really painful. Also does not account for any kind of intermittent
movement of the scrollbar.
I think you would agree a uniform FPS is more important than in-sync scrollbars?
No, I absolutely 100% disagree.
Synchronized updating so things don't vibrate or shift is more important
than FPS. It is even stated as part of Wayland's basic design criteria:
"every frame is perfect".
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
