New issue
Advanced search Search tips

Issue 679471 link

Starred by 1 user
Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Drawing of hidden elements when full screen canvas

Project Member Reported by mtrofin@chromium.org, Jan 9 2017 
To repro: load the page below. Open developer tools in separate window (and separate monitor). Click "full screen" on the page, so the canvas goes full screen. On the developer tools side, in the elements view, hover over the various html elements. 

On the rendered page side, it appears that the unrelated elements (other than the canvas) are still drawn.

It appears this causes ~20% overhead, as measured on OSX using this demo:
https://mtrofin.github.io/wasm-android-demo/webGL/webgl-teapots.htm



<html>
    <head>
        <title>WebGL - Teapots!</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <script>
            function fullScreen() {
                canvas = document.getElementById("glcanvas");
                if (canvas.requestFullscreen) {
                    canvas.requestFullscreen();
                } else if (canvas.webkitRequestFullscreen) {
                    canvas.webkitRequestFullscreen();
                } else if (canvas.mozRequestFullscreen) {
                    canvas.mozRequestFullscreen();
                }
            }
            function resizeCanvas() {
                canvas = document.getElementById("glcanvas");
                var isFullScreen = document.webkitIsFullScreen || document.mozFullScreen;
                if (isFullScreen) {
                    canvas.style.width = screen.width;
                    canvas.style.height = screen.height;
                } else {
                    canvas.style.width = 300;
                    canvas.style.height = 400;
                }
            }
        </script>
    </head>
    <body>
        <div>
            <p id='p1'>Some text in a div</p>
        </div>
        <p>
            <button type="button" onclick="fullScreen()">fullscreen</button>
        </p>
        <canvas id="glcanvas" width="300" height="400" onwebkitfullscreenchange="resizeCanvas()">
            Your browser doesn't appear to support the HTML5 <code>&lt;canvas &gt;</code>
            element.
    
        </canvas>
    </body>
</html>

Comment 1 by junov@chromium.org, Jan 9 2017

Components: Blink>Canvas
Owner: junov@chromium.org
Status: Assigned (was: Untriaged)
I think much of the overhead may be caused by the developer tools overlay layer being rendered on top of the page.  You should not make performance measurements with the elements view active.  I recommend using chrome://tracing as a less Heisenberg-ish means of collecting performance/profiling data.

Once you switch to Chrome tracing, you will see that there is some small amount of overhead on the main thread related to blink synchronizing with the compositor.  This can be further reduced by using the OffscreenCanvas API, which bypasses the blink commit entirely by pushing WebGL frames directly to the UI compositor.  OffscreenCanvas is currently an experimental feature. To use it, you need to enable "Experimental Canvas Features" in chrome://flags.

Comment 2 by mtrofin@chromium.org, Jan 9 2017 

The measurements were done with OSX Instruments, without dev tools on. The dev tools part is there as a detection of a symptom.

Now - I admit, the measurements were last carried early December. Could it be possible changes made it in the meantime? I will redo in that case.

I can try offscreen canvas, but I assume we'd want to have the same perf in the current (non-experimental) canvas.

Comment 3 by junov@chromium.org, Jan 10 2017 

Bringing the perf advantage of OffscreenCanvas to <canvas> will only be possible for fullscreen canvases.  We can make that happen, but that will likely be after we ship OffscreenCanvas, which is almost ready.

Comment 4 by mtrofin@chromium.org, Jan 17 2017 

I promised a trace on OSX. I created one using a more recent chromium build (Tip of tree the week of Jan 10), and uploaded it here: https://drive.google.com/drive/folders/0BzRscPk0VolKMWotaFhiMHBKVWM?usp=sharing

We spend 9% in UpdateLayers, visiting same URL mentioned earlier. Earlier I mentioned 20% - that's more like the percentage of time spent doing something other than drawing the frame.

Comment 5 by junov@chromium.org, Jan 17 2017 

Could you not use Chrome's tracing utility (chrome://tracing) for some reason?

What tool do I need to view this trace?

Comment 6 by mtrofin@chromium.org, Jan 17 2017 

Oh, I used XCode's Instruments. It's sampling-baed. Since chrome tracing is instrumentation-based, I preferred the former as it would introduce less noise - albeit, in this case, probably that doesn't matter, since we are observing something sufficiently large.

Would you prefer a chrome trace? If so, what metrics would be interesting?

Comment 7 by junov@chromium.org, Jul 25

Owner: ----
Status: Available (was: Assigned)
►

Sign in to add a comment