W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: [fullscreen] Problems with mouse-edge scrolling and games

From: Florian Bösch <pyalot@gmail.com>
Date: Mon, 24 Feb 2014 17:50:46 +0100
Message-ID: <CAOK8ODiV1Yq8aOkxZbKOfez9i3xHJ+=WivUki=AhW3rmvGd_OQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Thibaut Despoulain <thibaut@artillery.com>, Brandon Jones <bajones@google.com>, Ian Langworth <ian@artillery.com>, Webapps WG <public-webapps@w3.org>
On Mon, Feb 24, 2014 at 5:40 PM, Glenn Maynard <glenn@zewt.org> wrote:

> (More reasons: it's very likely that you'll end up implementing a cursor
> with different motion and acceleration, a different "feel", than the real
> mouse cursor.  It also breaks accessibility features, like mouse trails.)
Oh I agree, if your usecase fits a mouse cursor of the style that the OS
offers, it's definitely preferable to have the OS mouse cursor. And I
distinctly remember arguing prior to the pointerlock specification that it
would be immensely useful to have the ability to show the cursor, but
capture the pointer inside an area. And I was pointed, at the time, to the
solution to draw a software mouse cursor... So now what we're having this
discussion, I find appropriate to have pointed out as a possibility (to
draw the software cursor), which met some, let's call them "difficulties".
Now, I also just made a nice list which mentions 4 things to do, among
them, add this ability. I consider this now settled, because I think we all
agree on this. We might just need to agree on the limitations as they
partain to relative mouse movement reporting when you're showing the OS
cursor. And I think that's relatively easy to agree on, you can't rely on
relative motion outside of the constrained area if you show the OS cursor.

> This doesn't seem to relate to the discussion, which is about mouse
> pointers.
It is about input -> output, essentially. Intput as it comes from your
pointing device, and output, as it reflects in your application. The OS
mouse cursor is but one example of such reflection. There are many more
usecases that would like to benefit from a low input -> output latency, one
example of which is the variety of "software cursors" which may take the
shape of a picture, or something else completely. But moreover there are
usecases such as viewing controls that have the exact same need, notably
FPS shooters, for instance, or Oculus rift titles and so forth. So, it
matters a great deal to the, because you can alleviate some of the issues
while simultaneously solving a whole host of other issues.
Received on Monday, 24 February 2014 16:51:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:22 UTC