@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: [email protected] Tweet: @BKcore From: Brendan Eich Brendan Eich Reply: Brendan Eich [email protected] Date: February 24, 2014 at 9:47:24 AM To: Glenn Maynard [email protected] 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
