Canvas 2D lowlatency on CrOs doesn't show anything on the screen |
||||||||||
Issue descriptionThis is a sister-splinter bug of https://crbug.com/867025#c1 for Canvas 2D versions. Steps to repro: Compile and run a ToT (r577574) simplechrome on nautilus (or eve), with chrome:flags enable-experimental-web-platform-features set to "enabled" And with the lines around [0] commented out: // TODO( crbug.com/789232 ): Make low latency mode work with GPU acceleration if (LowLatencyEnabled()) return false; then: Navigate to https://codepen.io/miguelao/pen/EReOgO which essentially does: var ctx = canvas.getContext('2d', {lowLatency: true}); function draw_lines() { # Set color and line width. Then paint a line from and to a random location. ctx.moveTo(Math.random() * width, Math.random() * height); ctx.lineTo(Math.random() * width, Math.random() * height); ctx.stroke(); // Draw it } setTimeout( draw_lines, 5000 ) nothing shows up on the screen. There's a correct callstack to FinalizeFrame() that ends up in CanvasResourceProviderTextureGpuMemoryBuffer::ProduceFrame. The same codepen works: draws a random (random shade of green, random start and end points) line every 5s, when removing {lowLatency: true}. [0] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/canvas/html_canvas_element.cc?gsn=ShouldAccelerate2dContext&g=0&l=972
,
Jul 25
,
Jul 26
,
Jul 26
Adding the trace of the codepen in https://codepen.io/miguelao/pen/EReOgO manipulated to draw every 500ms; categories: bilnk, drm, viz.
,
Jul 26
,
Jul 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b63360e2a16d03144d748ff4179339fde2217c27 commit b63360e2a16d03144d748ff4179339fde2217c27 Author: Justin Novosad <junov@chromium.org> Date: Fri Jul 27 00:04:53 2018 Fix low latency 2D canvas updates The code was failing to flush deferred rendering commands recorded by Canvas2DLayerBridge before dispatching animation frames. This CL does not fix the problem completely: there is still an issue when the canvas is not gpu-accelerated BUG= 867601 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I32db0759af549ec6cd09ca677fff4ee215cae49e Reviewed-on: https://chromium-review.googlesource.com/1152028 Reviewed-by: Miguel Casas <mcasas@chromium.org> Commit-Queue: Justin Novosad <junov@chromium.org> Cr-Commit-Position: refs/heads/master@{#578493} [modify] https://crrev.com/b63360e2a16d03144d748ff4179339fde2217c27/third_party/blink/renderer/core/html/canvas/html_canvas_element.cc [modify] https://crrev.com/b63360e2a16d03144d748ff4179339fde2217c27/third_party/blink/renderer/platform/graphics/canvas_2d_layer_bridge.h
,
Jul 27
Low latency 2D canvas now uses gpu acceleration by default and that code path works. The non-accelerated code path is still broken. That code path uses shared memory bitmaps to push frames to the GPU process. Based on trace graph observations, it look like the frames are indeed being dispatched to the GPU process, and the display compositor is getting triggered, but it exits rapidly (35 microseconds). I have not had time to fully investigate, but I have a hunch that the an early exit condition is getting triggered in the display compositor. If we don't find a fix for this in a timely manner, plan B would be to force canvases to be GPU-accelerated (and remain GPU-accelerated) when low latency mode is requested, and to not enter low latency mode on systems that do not support gpu-accelerated 2d canvas, or if the canvas surface allocation falls back to software mode (e.g. out of GPU memory, max texture size exceeded, etc.)
,
Jul 30
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by mcasas@chromium.org
, Jul 25Labels: OS-Chrome