- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 12 Aug 2011 14:12:25 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: robert@ocallahan.org, Vincent Scheib <scheib@google.com>, Klaas Heidstra <klaas1988@gmail.com>, Brandon Andrews <warcraftthreeft@sbcglobal.net>, Olli@pettay.fi, Ryosuke Niwa <rniwa@webkit.org>, Adam Barth <w3c@adambarth.com>, "Gregg Tavares (wrk)" <gman@google.com>, Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, public-webapps@w3.org
On Fri, Aug 12, 2011 at 2:06 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Fri, Aug 12, 2011 at 1:54 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking <jonas@sicking.cc> wrote: >>> If we expose delta information in all mouse events, which seems like >>> it could be a good idea, then what is the usecase for the success >>> callback for mouselock? >>> >>> I was under the impression that that was so that the page could start >>> treating mousemove events differently, but if all mousemove events >>> have deltas, then that won't be needed, no? >> >> No, it's still definitely needed. You can't do an FPS with non-locked >> deltas; the user will end up moving their mouse off the screen. >> >> The use-cases for delta-without-mouselock are pretty separate from >> those for delta-within-mouselock. > > Sure, I wasn't saying that mouselock wasn't needed. I was asking what > the use case for the 'success' callback to the mouseLock was. So you can tell that you're locked. Without that assurance, you can't do a game using WASD+mouselook, because if the mouse isn't locked the user will end up scrolling out of your active area. You'll have to make sure the mouse is actually locked *somehow*; might as well be via a success callback. ~TJ
Received on Friday, 12 August 2011 21:13:20 UTC