On 08/07/2012 03:29 AM, Glenn Maynard wrote:
On Sat, Aug 4, 2012 at 4:24 AM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
5ms is quite low when the aim is 60Hz updates... but with
incremental/generational GCs 5ms sounds very much possible.
5ms is an
On Tue, Aug 7, 2012 at 2:29 AM, Glenn Maynard gl...@zewt.org wrote:
5ms is an *eternity* when you're aiming for 60 FPS, where you only have
16.6ms per frame to play with. That's 30% of your CPU budget just for
memory management. It doesn't matter if it's 5ms every 100 frames, since
it's the
On Sat, Aug 4, 2012 at 3:11 AM, Glenn Maynard gl...@zewt.org wrote:
On a quick test, Firefox is firing mousemove events at 120Hz; this is
about the same magnitude of data. We don't currently have any
infrastructure for using ArrayBuffers for complex data, so it'd either need
to be something
On Sat, Aug 4, 2012 at 11:07 AM, b...@pettay.fi b...@pettay.fi wrote:
The update rate depends on the device. Tablet updates reach way beyond
120HZ and even my 3D mouse clocks in at about 500 events/s. And a major
obstacle for a realtime input device is when the realtime app trying to
use it
On 08/04/2012 12:16 PM, Florian Bösch wrote:
On Sat, Aug 4, 2012 at 11:07 AM, b...@pettay.fi mailto:b...@pettay.fi b...@pettay.fi
mailto:b...@pettay.fi wrote:
The update rate depends on the device. Tablet updates reach way beyond
120HZ and even my 3D mouse clocks in at about 500
On Sat, Aug 4, 2012 at 11:24 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
It doesn't matter if they're bugs (I often see them in conjunction to
array buffer allocation).
Of course it matters. APIs shouldn't be designed based on implementation
bugs
It doesn't because those bugs have not
On Sat, Aug 4, 2012 at 11:31 AM, Florian Bösch pya...@gmail.com wrote:
On Sat, Aug 4, 2012 at 11:24 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
It doesn't matter if they're bugs (I often see them in conjunction to
array buffer allocation).
Of course it matters. APIs shouldn't be designed
On Sat, Aug 4, 2012 at 11:46 AM, Florian Bösch pya...@gmail.com wrote:
It's OK because the other half these projects owe it to array buffers to
make things run blazing fast, since the JIT in V8 enthusiastically
optimizes JS, the reduced pointer indirection speeds things up and the
better
Here's a rough sketch of an API that provides clean forwards-compatibility
for devices. I think this also avoids all of the issues I talked about
earlier: it gives a clean, easy to use event-based API that preserves
ordering and timestamps; it can be used in both an event-based and polling
way;
On Sat, Aug 4, 2012 at 7:03 PM, Glenn Maynard gl...@zewt.org wrote:
Here's a rough sketch of an API that provides clean forwards-compatibility
for devices. I think this also avoids all of the issues I talked about
earlier: it gives a clean, easy to use event-based API that preserves
ordering
On Sat, Aug 4, 2012 at 7:10 PM, Florian Bösch pya...@gmail.com wrote:
What happens if there is no supported profile?
Oh nm, then it's raw, stupid question.
On Sat, Aug 4, 2012 at 7:03 PM, Glenn Maynard gl...@zewt.org wrote:
I haven't tried to incorporate Florian's suggestion of using something
like ArrayBuffer. That could be supported later, eg. by providing a
readIntoBuffer(buffer) next to read(). That's too complex to try to tackle
all at
Sorry for the long-delayed reply. The tablets thread reminded me about
this mail, which got lost in the black hole known as drafts...
On Mon, May 7, 2012 at 2:33 PM, Scott Graham scot...@chromium.org wrote:
- As you point out, the 360 controller is by far the most common PC
gamepad, and on
On Sat, Aug 4, 2012 at 12:52 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, May 7, 2012 at 2:33 PM, Scott Graham scot...@chromium.org wrote:
- As you point out, the 360 controller is by far the most common PC
gamepad, and on its native platforms its standard API XInput is
exclusively
On Fri, Aug 3, 2012 at 6:17 PM, Florian Bösch pya...@gmail.com wrote:
There is a snag with deadzoning and axis ranges. Driver enumeration of
axes of an auto-calibrated device (or any device really) is often not
delivering any usable information on this. There is a zoo of
range/calibration
On Thu, May 3, 2012 at 9:14 PM, Glenn Maynard gl...@zewt.org wrote:
Here are some piecemeal thoughts on the subject of gamepads and the
gamepad spec. I havn't closely followed earlier discussions (and there
don't seem to have been any in a while), so much of this may have been
covered before.
Glenn, all of your points apply well to pressure sensitive pen input.
Pen vendors are not on the list, but their devices are quite similar.
I've changed the subject line and my responses are to your gamepad notes
in respect to their application to pen input.
Pen input in this case is pressure
snip
Weird, because you posted
this:
https://docs.google.com/document/d/1atsxnstVybfovkX_f6xf2P25i1NT0ilCihJuPDwYWEU/edit?hl=en_US
here: https://bugzilla.mozilla.org/show_bug.cgi?id=604039#c40
Just to be clear, I'm not trying to be aggressive or confrontational, but I
just reread my message
say the single event gamepagechanged, where the event object has a
property describing the complete state of the gamepad
That seems fine to me. One caveat is that XInput on Windows (for
example) is a polling-only API anyway, so it might not be reasonable
to expect better data in the event,
Here are some piecemeal thoughts on the subject of gamepads and the
gamepad spec. I havn't closely followed earlier discussions (and there
don't seem to have been any in a while), so much of this may have been
covered before.
- It should be possible to tell what's changed, not just the current
On 05/03/2012 12:48 AM, Rick Waldron wrote:
Instead of traditional DOM events being used for Other Events[1], and
considering the high frequency of Gamepad state changes, it might make
sense to provide an API similar to MutationObserver, where a
MutationRecord is created that has snapshots of
On Wed, May 2, 2012 at 5:54 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 05/03/2012 12:48 AM, Rick Waldron wrote:
Instead of traditional DOM events being used for Other Events[1], and
considering the high frequency of Gamepad state changes, it might make
sense to provide an API similar
On Wed, May 2, 2012 at 3:12 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Wed, May 2, 2012 at 5:54 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 05/03/2012 12:48 AM, Rick Waldron wrote:
Instead of traditional DOM events being used for Other Events[1], and
considering the high
On Wed, May 2, 2012 at 7:01 PM, Scott Graham scot...@chromium.org wrote:
On Wed, May 2, 2012 at 3:12 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, May 2, 2012 at 5:54 PM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 05/03/2012 12:48 AM, Rick Waldron wrote:
Instead of
On Wed, May 2, 2012 at 6:09 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Wed, May 2, 2012 at 7:01 PM, Scott Graham scot...@chromium.org wrote:
On Wed, May 2, 2012 at 3:12 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, May 2, 2012 at 5:54 PM, Olli Pettay olli.pet...@helsinki.fi
25 matches
Mail list logo
