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

@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, another software running in the background, etc.). This is why an OS-drawn cursor is so critical (in our use case that is, since we rely on a simple 2d cursor styled with CSS and not a 3d one)

Furthermore, when targeting low-end hardware, a 30fps render loop is enough for a decent graphical experience, while being completely mediocre and unplayable on the input side.

As for your last point, "Critical features for this use-case vendors have to offer, and soon”, we completely agree and would love to see those features implemented sooner than later.

-- 
WebGL guru @Artillery
Mail: thibaut@artillery.com
Tweet: @BKcore
From: Brendan Eich Brendan Eich
Reply: Brendan Eich brendan@secure.meer.net
Date: February 24, 2014 at 9:47:24 AM
To: Glenn Maynard glenn@zewt.org
Subject:  Re: [fullscreen] Problems with mouse-edge scrolling and games  
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 incremental GC (which BTW some browsers' JS  
engines have already, e.g., SpiderMonkey in Firefox), or as a real  
alternative, cross-compiling C or C++ for example via Emscripten, to  
allocate heap memory from a typed array.  

Florian, your goals are good, but the means to those ends must involve  
better runtimes or compilers -- not on JS programmers working harder to  
avoid GC while still somehow allocating objects frequently and even  
implicitly.  

/be