New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 604306 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Strange behavior with WebGL example

Project Member Reported by gman@chromium.org, Apr 18 2016

Issue description

Version: 52.0.2709.0 (Official Build) canary (64-bit) & 49.0.2623.112 (Official Build) (64-bit)
OS: OSX Early 2015 Macbook Pro

What steps will reproduce the problem?
(1) Run this example (https://jsfiddle.net/greggman/qLzrq8vh/)
(2) Wait about 10 seconds

What is the expected output?

In runs at 60fps for at least a relatively consistent framerate


What do you see instead?

Three different strange behaivors

#1)

After about 10 seconds it starts running at around 1fps for 3-4 seconds then goes back to 60fps BUT!!!! The time returned by performance.now() does not indicate any extra time elapsed. It's as though the system clock was stopped (or the chrome clock)

#2) 

Click the URL so it's got the focus. Press enter (so the page will reload but you didn't pick refresh).  More often than now this gets a WebGL hit a snag. Seems like there's zero reason for WebGL to crash there given for the most part it was running at 60fps.

#3)

Change `gl.TRIANGLE` to `gl.POINTS`. Now it will still run at 60fps for 5-10 seconds, then it will nearly freeze OSX. Given it actually runs fine for 5-10 seconds this sounds like a driver bug. I can only imagine memory issues of POINTS are CPU based??? No idea really.


I'm not sure any action is required here. I just wanted to bring it up in case someone what's to pursue it.


Firefox on the same machine runs this without the hiccups but also much slower. Firefox never hits 60fps but also never starts running at 1fps or less like Chrome.



 

Comment 1 by gman@chromium.org, Apr 19 2016

Status: WontFix (was: Untriaged)
Never mind I figured out the issue

The canvas if off screen so chrome isn't waiting for it. The delay after a while is just when the command buffer finally fills and it executes everything.

if I make the canvas visible it runs smooth

Comment 2 by kbr@chromium.org, Apr 19 2016

Cc: ccameron@chromium.org
OK, glad it's working. Note also that ccameron@ made some improvements to how Chromium handles GPU-bound content on Mac OS, specifically improving the back-pressure from the GPU to Chromium's rendering pipeline.

Sign in to add a comment