Reason for "Events MUST NOT be fired more than 30 times per second."

[happylinks]

I was curious what the reasoning behind this restriction is. Is it just to set a maximum in the spec, or is this a limitation to browsers/performance?
I could imagine some tools wanting to have the mouse coordinates at 60fps.

[eladalon1983]

Agreed. :-)

I've used 30fps as an arbitrary initial limit to keep things "sane" and performant. Imagine the extreme case of dragging the cursor across a 4k screen in the span of a second; you'd not want an individual event each time the cursor moves by a single pixel, causing the capturing app to slow down to a crawl.

But different applications will have different needs here. What do you think would be a good way to let an application tweak the behavior?

[happylinks]

Could maybe pass a configuration to the CaptureController? "mouseMoveInterval: 30" (bad name/bad value)

[eladalon1983]

That works for me. I wonder if we want to iterate over that later, though. IMHO, the MVP is to expose the coordinates with some reasonable regularity.

[happylinks]

Alright, then 30fps works for me!

[eladalon1983]

Sorry if I phrased things misleadingly. I think it's perfectly fine to kickstart the discussion right away. I was just proposing to view it as non-blocking for the initial specification and implementation. So if you're still interested, please re-open the issue, I'm happy to continue.

[fred-wang]

IIUC, this issue is about two things:

1. Explain the rationale for this 30 times per second.
2. Enhancement request to make the limit configurable in future iterations of the spec.

I guess (1) can be addressed immediately by adding some text in the spec, perhaps in a non-normative <div class="note">. Do we want that?

For (2) the discussions we had in other issues, @eladalon1983's proposal was to use labels on GitHub issues for future features and then to close them immediately (personally I prefer keep them open with labels).

In any case for (2) I'd suggest either to open a separate issue or to change the title, something like "Make frequency of CapturedMouseEvents configurable" so it's easier to understand what the issue is about when reviewing the list of open issues.

[eladalon1983]

For (2) the discussions we had in other issues, @eladalon1983's proposal was to use labels on GitHub issues for future features

It makes sense to me to keep this issue open, because it deals with either (a) something already in the spec or (b) something we're proposing to add to the spec right now. Does that make sense?

"Make frequency of CapturedMouseEvents configurable" so it's easier to understand what the issue is about when reviewing the list of open issues.

That works for me.

[fred-wang]

It makes sense to me to keep this issue open, because it deals with either (a) something already in the spec or (b) something we're proposing to add to the spec right now. Does that make sense?

OK sure, but from your comment "non-blocking for the initial specification and implementation" I understood it was for a later iteration.

That works for me.

@happylinks Are you also ok to rename this issue ""Make frequency of CapturedMouseEvents configurable" ?