3 ms·

That is very cool. I got quite bad rubber banding initially (with a reported 60fps), however after turning off v-sync in chrome://flags I got super smooth 120fp

by ux-app 13y ago

That is very cool. I got quite bad rubber banding initially (with a reported 60fps), however after turning off v-sync in chrome://flags I got super smooth 120fps performance. Would be great if Chrome had this option off by default.

exDM69 13y ago
> Would be great if Chrome had this option off by default. Disabling Vsync causes page tearing artifacts (https://en.wikipedia.org/wiki/Page_tearing https://en.wikipedia.org/wiki/Page_tearing). It should always be enabled by default. Some new gpu drivers also have "adaptive vsync", where it's enabled by default but gets temporarily disabled when deadlines are not met.
- ux-app 13y ago
  isn't tearing preferable to input lag? As I mentioned, with v-sync on there is a very noticeable rubber-banding effect, with it off the result is (perceptually) far smoother. >It [vsync] should always be enabled by default Not sure about this. Surely the goal is to maximize perceived performance not 'correctness' (where correctness in this context is defined as each frame being fully drawn before the next one starts).
  - exDM69 13y ago
    > isn't tearing preferable to input lag? In a properly written app, vsync should not cause input lag despite gamer superstitions. But there are lots of not-properly written apps where this is a problem. WebGL / Chrome should solve the problem in some other way, not disabling vsync. Or using adaptive vsync if available as a workaround. The culprit here might be the ANGLE OpenGLES2-on-D3D9 wrapper that Chrome uses, which is notoriously slow on synchronous operations like vsync, glGetError or glFinish.
just2n 13y ago
That was just caused by me not processing input properly. I've set up a proper rendering loop here and now only render the most recent mouse position on each frame: http://jsfiddle.net/eymAS/84/ http://jsfiddle.net/eymAS/84/ It's better, but still limited to 60fps, and since I render to the state at 0s, the worst delay we can see is ~16.6ms + rendering time.

by ux-app 13y ago

exDM69 13y ago

> Would be great if Chrome had this option off by default. Disabling Vsync causes page tearing artifacts (https://en.wikipedia.org/wiki/Page_tearing https://en.wikipedia.org/wiki/Page_tearing). It should always be enabled by default. Some new gpu drivers also have "adaptive vsync", where it's enabled by default but gets temporarily disabled when deadlines are not met.

ux-app 13y ago
isn't tearing preferable to input lag? As I mentioned, with v-sync on there is a very noticeable rubber-banding effect, with it off the result is (perceptually) far smoother. >It [vsync] should always be enabled by default Not sure about this. Surely the goal is to maximize perceived performance not 'correctness' (where correctness in this context is defined as each frame being fully drawn before the next one starts).
- exDM69 13y ago
  > isn't tearing preferable to input lag? In a properly written app, vsync should not cause input lag despite gamer superstitions. But there are lots of not-properly written apps where this is a problem. WebGL / Chrome should solve the problem in some other way, not disabling vsync. Or using adaptive vsync if available as a workaround. The culprit here might be the ANGLE OpenGLES2-on-D3D9 wrapper that Chrome uses, which is notoriously slow on synchronous operations like vsync, glGetError or glFinish.

just2n 13y ago

That was just caused by me not processing input properly. I've set up a proper rendering loop here and now only render the most recent mouse position on each frame: http://jsfiddle.net/eymAS/84/ http://jsfiddle.net/eymAS/84/ It's better, but still limited to 60fps, and since I render to the state at 0s, the worst delay we can see is ~16.6ms + rendering time.