https://www.w3.org/Bugs/Public/show_bug.cgi?id=24790
Art Barstow changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24790
Bug ID: 24790
Summary: "Developers must not pass false for the async ar..."
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
S
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24789
Bug ID: 24789
Summary: "Developers must not pass false for the async ar..."
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
S
Exactly. Having an “exit from fullscreen” bar or some OS auto-hide elements
like docks and task bars popping up at the edges when you play an intense
twitch game is simply horrendous. We have several playtests feedbacks arguing
in that direction.
Not to mention that a lot of our alpha players
On Mon, Feb 24, 2014 at 8:21 PM, Glenn Maynard wrote:
>
> I think that going fullscreen is the right approach, since locking the
> mouse into the window while not fullscreen is really weird and rare, at
> least in Windows.
>
It's quite common for games to have a cursor, grab the pointer and not be
On Mon, Feb 24, 2014 at 12:19 PM, Florian Bösch wrote:
> Like I say, some usecases are fine with OS cursors. But that doesn't mean
> that somehow, vendors are absolved from improving input -> output latency
> issues even if pointerlock is updated to allow OS cursor showing, which I'm
> all for.
>
Right, so you'd CGAssociateMouseAndCursorPosition(false) and then use
CGWarpMouseCursorPosition or CGDisplayMouseCursorToPoint to move it where
you want it to be, but clamped inside the rect. As long as you keep pumping
the event loop separately that does this (as fast as possible) it shouldn't
be
On Mon, Feb 24, 2014 at 10:37 AM, Florian Bösch wrote:
> On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib wrote:
>
>> Windows has ClipCursor() and Linux has XGrabPointer(). Once we know we
>> can implement the functionality, we can discuss how to express this in an
>> API.
>>
>
> Would using Quar
On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib wrote:
> Windows has ClipCursor() and Linux has XGrabPointer(). Once we know we can
> implement the functionality, we can discuss how to express this in an API.
>
Would using Quarz CGWarpMouseCursorPosition work where you'd clamp the
passed positio
On Mon, Feb 24, 2014 at 6:47 PM, Brendan Eich wrote:
> Glenn Maynard wrote:
>
>> It's not the application's job to keep the mouse cursor responsive, it's
>> the system's. Hiding the system mouse cursor and drawing one manually is
>> always a bad idea.
>>
>
> Agreed!
>
Like I say, some usecases a
@Florian:
That is very well put.
Trust me, we are well aware of time budgets and GC pauses. The thing is that
even when planning frame budgets and object allocations ahead, you still have
external parameters you cannot really control (ie. Another tab running flash or
some other intensive task,
Thank you Ian for the clear use case write up (and to Artillery for
progress on a great product), Florian Brandon and Glenn for discussion &
contributions.
As Florian mentioned, we did discuss this use case in 2011 and at that time
I attempted to summarize the situation in the pointer lock spec FA
Glenn Maynard wrote:
It's not the application's job to keep the mouse cursor responsive,
it's the system's. Hiding the system mouse cursor and drawing one
manually is always a bad idea.
Agreed!
In the same vein, programmers cannot avoid GC pauses without relying on
pause-free or at least in
On Mon, Feb 24, 2014 at 5:40 PM, Glenn Maynard 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
(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.)
On Mon, Feb 24, 2014 at 10:30 AM, Florian Bösch wrote:
> On Mon, Feb 24, 20
On Sunday, February 23, 2014 at 8:53 AM, Mitar wrote:
> Hi!
>
> After a bit of delay, I posted a followup to the WHATWG mailing list:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-February/042100.html
Looks great, Mitar. I'm sure Hixie and folks at the WHATWG will respond soon
On Mon, Feb 24, 2014 at 5:18 PM, Glenn Maynard wrote:
>
> It's not the application's job to keep the mouse cursor responsive, it's
> the system's. Hiding the system mouse cursor and drawing one manually is
> always a bad idea.
>
That's a wonderful argument. And now we look at an FPS game, or an
On Mon, Feb 24, 2014 at 4:17 AM, Florian Bösch wrote:
> On Mon, Feb 24, 2014 at 1:16 AM, Thibaut Despoulain > wrote:
>
>> I've written a test for this here:
>>> http://codeflow.org/issues/software-cursor.html
>>>
>>> My observation from testing on linux is that I can't distinguish latency
>>> f
Also: At the moment we're using CSS cursors to give visual feedback on
in-game hover/action states which works pretty well and is a breeze to
implement.
On Sun, Feb 23, 2014 at 4:16 PM, Thibaut Despoulain
wrote:
> I've written a test for this here:
>> http://codeflow.org/issues/software-cursor.h
The issue with pointerlock is that it requires the app to draw its own
cursor instead of the OS cursor, which has at least two significant
drawbacks:
- Significant pointer lag between movement input and actual movement on
screen compared to an OS-drawn cursor (yes, even at 60fps),
- Inabi
>
> I've written a test for this here:
> http://codeflow.org/issues/software-cursor.html
>
> My observation from testing on linux is that I can't distinguish latency
> for the software cursor from the OS cursor (or not by much anyway) in
> google chrome. In firefox however there's noticable lag. Mi
On Mon, Feb 24, 2014 at 1:16 AM, Thibaut Despoulain
wrote:
> I've written a test for this here:
>> http://codeflow.org/issues/software-cursor.html
>>
>> My observation from testing on linux is that I can't distinguish latency
>> for the software cursor from the OS cursor (or not by much anyway) in
22 matches
Mail list logo
