Issue 86287 in chromium: Slow hardware-accelerated canvas rendering
chro...@googlecode.com
Owner: ----
Labels: Type-Bug Pri-2 Area-Undefined OS-Windows
New issue 86287 by kom...@gmail.com: Slow hardware-accelerated canvas
rendering
http://code.google.com/p/chromium/issues/detail?id=86287
Chrome Version : 14.0.793.0
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) : http://kothic.org/js/
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: OK
Firefox 4.x: OK
Opera: OK
What steps will reproduce the problem?
1. Go to the page, wait for it to fully render the screen
2. In debug panel on the right, look at Total time to render a tile
3.
What is the expected result?
Tiles are rendered within 1-2 seconds (the faster the better)
What happens instead?
Tiles are rendered for 27 seconds and more.
Please provide any additional information below. Attach a screenshot if
possible.
This is today's canary build on Windows. That didn't happen yesterday's
build, but it appears it didn't have fix for Anti-Aliasing
(http://code.google.com/p/chromium/issues/detail?id=85762). Today's build
has smooth antialiased graphics but slow performance.
UserAgentString: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML,
like Gecko) Chrome/14.0.793.0 Safari/535.1
chro...@googlecode.com
Comment #1 on issue 86287 by kom...@gmail.com: Slow hardware-accelerated
canvas rendering
http://code.google.com/p/chromium/issues/detail?id=86287
This does not happen on Linux, Chrome 13.0.782.24 (Official Build 89139)
dev, accelerated canvas, NVidia drivers.
chro...@googlecode.com
Labels: -Area-Undefined Area-Internals Feature-GPU
Comment #2 on issue 86287 by tha...@chromium.org: Slow hardware-accelerated
canvas rendering
http://code.google.com/p/chromium/issues/detail?id=86287
(No comment was entered for this change.)
chro...@googlecode.com
Comment #3 on issue 86287 by quarkste...@gmail.com: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
on Win Vista 64 with "Google Chrome 14.0.793.0 canary" and other 3d
applications in the background it needs about 7,5 seconds (7500ms) per tile
to render on my computer.
chro...@googlecode.com
Comment #6 on issue 86287 by tomh...@google.com: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
(Units of path length above should be bytes, not verts/points - 4k-112k B
vertex buffer is a bit more reasonable.)
chro...@googlecode.com
Blockedon: 86488 86490
Comment #7 on issue 86287 by tomhud...@chromium.org: Slow
hardware-accelerated canvas rendering
http://code.google.com/p/chromium/issues/detail?id=86287
(No comment was entered for this change.)
chro...@googlecode.com
Comment #8 on issue 86287 by tomh...@google.com: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
overtesselation: per
http://code.google.com/p/chromium/issues/detail?id=86488, most of the huge
paths in the target dataset are sequences of short lines (i.e. building
outlines), so changing tessellation tolerance of cubics & quadratics has a
minimal effect - the huge paths were not the result of overtessellation.
We'd like to make the patch anyway for correctness, although it will stomp
on a large number of layout tests and so be difficult to land.
blocking: per http://code.google.com/p/chromium/issues/detail?id=86490,
even without vertex buffer creation we're stuck in the GPU. We're currently
changing Skia to make it easier to reuse the same vertex & index buffers
for each of the tiles, but are doing that with significant replumbing
rather than a quick hack.
chro...@googlecode.com
Comment #9 on issue 86287 by tomh...@google.com: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
bsalomon@ tried improving vertex & index buffer reuse, but still sees a CPU
spending most of its time waiting for the GPU - now because of lack of room
in the command buffer. Next steps: getting annotated about:gpu traces to
the Chrome-GPU team for advice, trying to increase the space in the command
buffer, clipping each path to the AA tile being rendered to control for
possible fill limitations.
chro...@googlecode.com
Comment #11 on issue 86287 by kom...@gmail.com: Slow hardware-accelerated
canvas rendering
http://code.google.com/p/chromium/issues/detail?id=86287
20% speedup sounds cool, but it renders no more than 3 seconds on non-GPU
canvas and ~27 seconds on GPU one - that sounds as fantastic difference for
me.
If it is slow because of antialiasing, can we have some way of
enabling/disabling it from inside of the map renderer?
Are there any other optimizations that can be done in javascript code that
won't hurt other browsers?
chro...@googlecode.com
Comment #12 on issue 86287 by kom...@gmail.com: Slow hardware-accelerated
canvas rendering
http://code.google.com/p/chromium/issues/detail?id=86287
I counted all the lineTo's in tiles to have some idea of tiles complexity.
Here's what I see in Chrome 14.0.803 if i zoom in once:
http://latlon.org/~komzpa/text-rotate-canvas/chrome14-gpcanvas-segments-and-time-correlation.png
There probably should be almost linear correlation between "map rendered"
(when all those strokes are moveTo'ed and stroke'd), but I don't see one -
13630 / 6996. = 1.948 ms/stroke
4028 / 8634. = 0.466 ms/stroke
27954 / 60423. = 0.462 ms/stroke
45168 / 40195. = 1.123 ms/stroke
In Firefox on the same machine, things are more linear:
http://latlon.org/~komzpa/text-rotate-canvas/firefox7-canvas-segments-and-time-correlation.png
>>> 2977 / 22236. = 0.133 ms/stroke
>>> 252 / 8634. = 0.0291 ms/stroke
>>> 945 / 40195. = 0.0235 ms/stroke
>>> 2804 / 60423. = 0.0464 ms/stroke
Things are like 20 times faster there. Am I counting something wrong?
chro...@googlecode.com
Cc: z...@chromium.org
Comment #16 on issue 86287 by tomhud...@chromium.org: Slow
hardware-accelerated canvas rendering
http://code.google.com/p/chromium/issues/detail?id=86287
We'd like to see more speedup in antialiasing, but we don't expect anything
like an order of magnitude. It sounds like the original reporter's hardware
isn't going to be up to rendering complex AA paths; software is likely to
be fast enough. Can we blacklist the hardware and fall back to software? Is
there a way to rule out a broad range of GPUs, or do we have to pick them
out one at a time as we get reports of poor performance?
chro...@googlecode.com
Comment #17 on issue 86287 by axk...@gmail.com: Slow hardware-accelerated
canvas rendering
http://code.google.com/p/chromium/issues/detail?id=86287
Dear Google Team, I took now the time to write an "idealized" test script
of my application. Quick Result: Canary is about 5 times slower than Google
12, even with disabled GPU.
What I'm doing is using a lot of little canvases as buffer. Since their
contents do not change often and are slow to draw since they consist mainly
of Text generated with fillText(). For the test a gradient sufficided.
Setup:
Test: http://homepage.univie.ac.at/axel.kittenberger/speed.html
It draws 100 times 100 little canvases on a big one. I tested on two
Machines, my Laptop, a somewhat dated Dell Machine (D430) and my Mac Mini.
Results:
Dell D430 Notebook (Windows 7, latest updates)
Firefox 5.0:
6,707 ms; 6,727 ms; 6,626 ms
Chrome 12.0.742.122:
3,084 ms; 3,131ms; 3,142ms
Chrome 14.0.832.0:
14,736 ms; 16,649 ms; 14,547 ms
Chrome 14.0.832.0: (disabled GPU)
14,281 ms; 14,321 ms; 14,880 ms
Opera 11.5:
11,396ms, 10,792ms; 11,566ms
IE9 :
31,353ms; 32,208ms; 33,431 ms
Safari: 5.0.5
after about 13 seconds complains with a message), takes aprox another 2
seconds after I hit OK.
----------------------
Mac Mini, OSX 10.6.8::
Firefox 5.0.1:
3,311 ms; 3,342 ms; 3,347ms
Safari 5.05:
3,140 ms; 3,117 ms; 3,087ms
Chrome 12.0.742.122:
3,703 ms; 3,733ms; 3,650ms
Chrome 14.0.833.0:
3,636 ms; 3,559 ms; 3,530 ms
Discussion:
On the MacMini/OSX the performance is about equal of everything. However,
on the Windows Laptop there are very large differences. The clear winner is
Chrome 12. The clear loser IE9, which came to a surprise to me, since
normal testing with the actual webapplications it felt quite responsive.
Canary is really a lot slower than Chrome 12. Even disabling the GPU
acceleration in about:flags did not change much. I did close everything and
restarted Canary. So unless I made a stupid error, it really should have
been disable. The results are not too exact, since I retested Firefox 5.0
at the end to test reliability and then it then took about 8000ms. I
suppose my CPU was slowed due to heat and it started to smell a little,
since the laptop rested on its leather transporting sheath.
chro...@googlecode.com
Comment #18 on issue 86287 by tomh...@google.com: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
Thanks for the detailed test case. Small canvases is a different issue than
path antialising, and was represented by
https://bugs.webkit.org/show_bug.cgi?id=64958. I'll keep an eye on this;
hopefully you'll see real improvement in a canary/dev build soon.
chro...@googlecode.com
Comment #20 on issue 86287 by agafon...@gmail.com: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
Is 10 times drop in Canvas performance really non-critical?
chro...@googlecode.com
Comment #21 on issue 86287 by yonathan: Slow hardware-accelerated canvas
rendering
http://code.google.com/p/chromium/issues/detail?id=86287
This is a severe regression on my machine; many canvas pages are completely
unusable on my Thinkpad X41 with no hardware acceleration (Ubuntu 11.04).
Here are my results for axkibe's speed.html test:
12.0.742.124 (Official Build 92024): Test took 5274ms
14.0.825.0 (Official Build 92801) dev: Test took 638857ms
14.0.835.8 (Official Build 94414) dev: Test took 619483ms
Graphics: Mesa 7.10.2. No hardware acceleration.
In this translation test http://jsfiddle.net/HRVz6/2/embedded/result/ (from
bug http://crbug.com/87097), the non-translated version still works fine
and quickly, but the translated version is very very slow.
chro...@googlecode.com
Comment #22 on issue 86287 by tomhud...@chromium.org: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
Yonathan,
Thanks for the bug report. That's a separate issue, and I opened
http://code.google.com/p/chromium/issues/detail?id=91200 to track it.
chro...@googlecode.com
Comment #30 on issue 86287 by komzpa: Slow hardware-accelerated canvas
rendering
http://code.google.com/p/chromium/issues/detail?id=86287
--disable-accelerated-layers helped here; now it renders in 1.9 seconds.
Red borders were on [+/-] control and on panel on the right, after restart
with --disable-accelerated-layers it is fast and no red borders are shown.
Chrome 15.0.874.1 (Official Build 99955) dev; ATI Radeon Mobility HD4200.
chro...@googlecode.com
Comment #31 on issue 86287 by tomh...@google.com: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
From what you've said previously, it sounds like there isn't enough GPU
memory on your machine to support the compositor, and the machine ought to
be blacklisted; I don't know why you're getting the accelerated layers when
about://gpu says it's disabled.
Zhenyao, does this behavior make sense to you? (qv comments #25 & #30)
Also, komzpa@, when you say "1.9 seconds", is that what the JavaScript
widget on the right reports for a *single* tile, or the sum of all 4
numbers it reports? One of the sources of confusion that we've had is that
those timers are all running in parallel, so if you have 4 timers that say
500 ms each, the total time spent is still < 1 second. I made comment #5
before I understood this, so the "total time" value there is very
inaccurate.
chro...@googlecode.com
Comment #32 on issue 86287 by komzpa: Slow hardware-accelerated canvas
rendering
http://code.google.com/p/chromium/issues/detail?id=86287
"1.9 seconds" and all the other numbers referred by me are taken for single
tile. And without commandline flags it's still over 10 seconds.
Here's screenshot of numbers I see:
http://latlon.org/~komzpa/screenshots/kothic/chrome-10sec.jpeg
chro...@googlecode.com
Comment #37 on issue 86287 by hlfcod...@gmail.com: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
Really? Normal priority? Half of your own promotional material doesn't work
right: http://www.chromeexperiments.com. This kind of attitude discourages
creative developers from moving into the browser. Glad to see it's coming
up, but please reprioritize it.
chro...@googlecode.com
Comment #38 on issue 86287 by samole...@gmail.com: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
It seems that this problem have been fixed on 16.0.891.0 dev-m
The website I posted in comment 36 works again now :D
chro...@googlecode.com
Comment #39 on issue 86287 by tkrou...@gmail.com: Slow hardware-accelerated
canvas rendering
http://code.google.com/p/chromium/issues/detail?id=86287
Same problem:
Software rendering flies.
"Hardware" rendering super-slow.
Windows 7, 64bit.
Intel mobile 965 chipset (Intel 965 graphics chip) + Intel v8.15.10.1930
drivers.
On Chrome 14.0.835.202 m and 16.0.909.0 canary, tried various demos from
here:
http://flashcanvas.net/example/demo
With "GPU Accelerated Canvas 2D" = Enabled in about:flags (and FPS Counter
Enabled) see shamefully substandard frame rate. With "GPU Accelerated
Canvas 2D" = Disabled (option available only on 14.x, not on 16.x, so tried
only on 14.x) Canvas flies, rendering is smooth as butter. Obviously, IE9,
Opera, Safari, FF are orders of magnitude faster on same machine
than "default" (Accel Canvas = On) Chrome on same machine.
The chipset - intel 965 - needs to be blacklisted for "accellerated" Canvas
2D. It's on so many laptops, and default Chrome v14-on canvas performance
on these lappies is shameful.
Recommend having browser do some (overt) rendering tests on a machine
post-install and setting "accelleration" On/Off depending on test results.
As is, shoving Accell ON onto users and hoping for the best obviously did
not work well for Chrome/ium for 3 major version.
I wonder if Android's slower-than-competition canvas performance on 2.3.x
is due to the same "accelleration" thing...
chro...@googlecode.com
Comment #50 on issue 86287 by raya...@chromium.org: Slow
http://code.google.com/p/chromium/issues/detail?id=86287
Tested between 17.0.963.56 and 18.0.1025.33
Mobile Intel(R) 965 Express Chipset Family (GPU Card)
M17: Not Loading..
M18: Not Loading..
FF: Not Loading..
IE: Not Loading..
chro...@googlecode.com
Status: Fixed
Comment #54 on issue 86287 by wiltz...@chromium.org: Slow
hardware-accelerated canvas rendering
http://code.google.com/p/chromium/issues/detail?id=86287
I agree with you, Brian; let's close this as fixed for now but continue to
use kothic.org as a test case.