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

Re: Mouse Capture for Canvas

From: Brandon Andrews <warcraftthreeft@sbcglobal.net>
Date: Tue, 8 Feb 2011 18:55:15 -0800 (PST)
Message-ID: <268098.95191.qm@web83810.mail.sp1.yahoo.com>
To: robert@ocallahan.org, Kenneth Russell <kbr@google.com>
Cc: public-webapps@w3.org
(Not sure how to reply to a mailing list with yahoo mail so this might not work 
or it might)

On Tue, Feb 8, 2011 at 5:49 PM, Robert O'Callahan <robert@ocallahan.org> wrote: 
> On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell <kbr@google.com> wrote: >> >> 
This API doesn't handle all of the desired use cases. In particular, >> to 
implement Quake-style mouse look (needed for e.g. >> 
http://code.google.com/p/quake2-gwt-port/) it needs to work when the >> mouse 
button is up, not just down. > > How would you satisfy that use-case without 
enabling abusive behavior by Web > sites?
>
> (I think that case would work with our API if the game was full-screen, > which 
>I expect it normally would be.) > > Rob

Actually this would be used for both fullscreen and non-fullscreen applications.
The reason for this is because it's often CPU intensive to run a complex canvas
application in fullscreen. Another key part that Kenneth mentioned was the 
ability
to get deltaX and deltaY of the mouse which is very powerful when you have the
mouse locked. In games this allows you to move your mouse to edge of the canvas
element and continue to detect mouse changes whereas in a fullscreen application
moving your mouse to the left side will lock to 0 for the x mouse position even 
though the mouse may still be moving left. The deltaX would say like -12 for
instance showing the person is still moving left. Hopefully that clears things 
up.
Received on Wednesday, 9 February 2011 02:55:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT