Software renderer slow to render SVG filter animation frames
Reported by
dukedou...@gmail.com,
Aug 27
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: Refer to attached zipfile for code and instructions, also for a Chromium trace. What is the expected behavior? Headless Chrome beginframe is fast to generate frames What went wrong? I am generating animation frames from CSS animations using Headless Chrome on an Amazon EC2 m3.medium 64-bit 1vcpu 3.75GB RAM. It takes about 8 seconds to generate 125 frames of 400X400 pixel animation. To give some context hopefully not being too dramatic, pretty much any 2d game on any computer of the past 10 to 20 years should be able to easily do better than this, but in this case, a machine running nothing but one tab on a Chrome instance on a machine doing nothing else takes 8 seconds to generate 125 frames. Illustrating the case from the other direction - what modern machines are capable of when running 2d games... illustrates the point further that this is really very slow indeed. Of course the frames are being converted to base64 but even that probably doesn't account for how slow this is.... which is to say very slow indeed. I have attached a zipfile that includes a Chromium trace, some notes and code explaining how to reproduce. I have also tried using virtual time and the results are the same. Perhaps my coding approach is wrong, which would be good news, but I've tried alot to eke out more performance with no luck so far. Did this work before? N/A Chrome version: 68.0.3440.106 Channel: stable OS Version: Ubuntu 18.04 Flash Version: Google Chrome 70.0.3514.0 dev
,
Aug 27
,
Aug 28
The trace shows that SoftwareRenderer::DoDrawQuad takes particularly long (~40ms per frame). My guess is that this is simply because the SoftwareRenderer isn't very efficient when drawing the SVG filter animation in your example. (Copying into JSON/base64 isn't fast either, but the majority of time is spent actually rendering the frames.) I could repro the slow draw a little easier using your example page without the need for NodeJS / BeginFrameControl: 1. Download test case from #0. 2. Execute: chrome --headless --trace-startup=* --trace-startup-duration=10 --remote-debugging-port=9222 file:///path/to/chromiumtestcase/squiggly-text/index.html 3. Open chrometrace.log in chrome://tracing (also attached here). So I think the real issue here is that the software renderer is slow. One more thing I discovered: If you run the above with a debug build, chrome actually crashes hitting a DCHECK: [0828/145602.883346:INFO:SkImageFilter.cpp(202)] ../../third_party/skia/src/core/SkImageFilter.cpp:202: fatal error: "assert(!inputRect)" Received signal 6 #0 0x7fb6a222dcfc base::debug::StackTrace::StackTrace() #1 0x7fb6a222d7d1 base::debug::(anonymous namespace)::StackDumpSignalHandler() #2 0x7fb69653d0c0 <unknown> #3 0x7fb6943d0fcf gsignal #4 0x7fb6943d23fa abort #5 0x7fb6a19c8275 sk_abort_no_print() #6 0x7fb6a1d3519e SkImageFilter::filterBounds() #7 0x7fb6a1eb90fb SkComposeImageFilter::onFilterBounds() #8 0x7fb6a1d351b3 SkImageFilter::filterBounds() #9 0x7fb692d76f5f viz::SoftwareRenderer::ApplyImageFilter() #10 0x7fb692d75e59 viz::SoftwareRenderer::DrawRenderPassQuad() #11 0x7fb692d75336 viz::SoftwareRenderer::DoDrawQuad() #12 0x7fb692d2f37e viz::DirectRenderer::DrawRenderPass() #13 0x7fb692d2e2cb viz::DirectRenderer::DrawRenderPassAndExecuteCopyRequests() #14 0x7fb692d2dcee viz::DirectRenderer::DrawFrame() #15 0x7fb692d33fe8 viz::Display::DrawAndSwap() #16 0x7fb692d40f80 viz::DisplayScheduler::DrawAndSwap() #17 0x7fb692d405f3 viz::DisplayScheduler::AttemptDrawAndSwap() #18 0x7fb692d3fd5a viz::DisplayScheduler::OnBeginFrameDeadline() +danakj might be able to help triage further.
,
Aug 31
Not sure how much is expected from doing the actual filter work? |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by bugsnash@chromium.org
, Aug 27