W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Mouse Lock

From: Gregg Tavares (wrk) <gman@google.com>
Date: Tue, 28 Jun 2011 00:54:29 -0700
Message-ID: <CAKZ+BNrboRgyeg3hRtc-ijy7bdFy_m4ApE8x5E2nOEVnbUEBxw@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, Simon Pieters <simonp@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Adam Barth <w3c@adambarth.com>, Vincent Scheib <scheib@google.com>, Brandon Andrews <warcraftthreeft@sbcglobal.net>, Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, robert@ocallahan.org, public-webapps@w3.org
On Mon, Jun 27, 2011 at 6:17 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Mon, Jun 27, 2011 at 8:59 PM, Gregg Tavares (wrk) <gman@google.com>wrote:
>> As far as I know if a game wants to limit movement of the mouse inside a
>> window they just mouselock and display their own mouse pointer. The original
>> is hidden and their pointer logic uses the deltas to move their software
>> mouse pointer.
> Rendering a cursor manually is a non-option.  It invariably results in a
> laggy mouse cursor, even in native applications.  Even a single extra frame
> of latency makes a mouse painful to use.

I beg to differ. Nearly every game that has a mouse renders a mouse cursor
manually. At least all the ones I've played. I quick search on youtube for
"rts gameplay" shows this is true.

The point is, 1 it's unrelated to mouselock, 2 you can implement it on top
of mouselock for now. If that's too slow for your app and there's a huge
need something else can be added later.

> But again, this seems like an unrelated feature.
> --
> Glenn Maynard
Received on Tuesday, 28 June 2011 07:54:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:20 UTC