Open Bug 599236 Opened 11 years ago Updated 11 years ago
Chrome Experiment "Video->ASCII" slower than in Chrome at higher resolutions
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:188.8.131.52) Gecko/20100914 Firefox/3.5.13 Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100923 Firefox/4.0b7pre This experiment converts streaming video pixels to ASCII characters, which are then drawn to the canvas to recreate the moving video. Higher "resolutions" are achieved technically by reducing the font size, though options also exist to change canvas size as well. Reproducible: Always Steps to Reproduce: 1. Load page 2. Play video 3. Use slider to adjust the resolution of the video to maximum Actual Results: ASCII representation will have slight lag behind the actual video on max resolution on both Minefield and Chrome, though lag time is noticeably higher on Minefield than on Chrome on higher resolutions. Toggling hardware acceleration does not seem to help.
Summary: Chrome Experiment "Video->ASCII" slower than Chrome at higher resolution → Chrome Experiment "Video->ASCII" slower than in Chrome at higher resolutions
Playing around with hardware acceleration, it seems as though Chrome outperforms FF regardless of whether FF has hardware acceleration enabled. The difference is more noticeable in the real life "Never Gonna Give You Up" video than in the animated iPod ad (can toggle between the two at the bottom). My video card information: Adapter Description NVIDIA GeForce 9300 GE Vendor ID 10de Device ID 06e0 Adapter RAM 256 Adapter Drivers nvd3dum nvwgf2um,nvwgf2um Driver Version 184.108.40.20696 Driver Date 7-9-2010 Direct2D Enabled true DirectWrite Enabled true GPU Accelerated Windows 1/1 Direct3D 9
Rule #4839 of bugzilla: in all potentially Direct2D-related bugs, i.e. all 2D graphics performance bugs on Windows Seven / Vista, thou shalt CC Bas.
(In reply to comment #1) > Created attachment 478175 [details] > CPU profiling for the event Hi Steven, can you include D2D1.dll and dwrite.dll? Only 9% of CPU time is spent in xul.dll in your screenshot, compared to 25% in FF.
Thanks for CC'ing bas again, bjacob :) Should I be CC'ing you as well on bugs like this and bug 598834? Also, please let me know if there's anything else I can/should provide.
The top section "Unknown" is collapsed for brevity, it contains calls made to NVidia graphics card drivers.
Attachment #478175 - Attachment description: CPU profiling for the event → CPU profiling within xul.dll
(In reply to comment #5) > Thanks for CC'ing bas again, bjacob :) > Should I be CC'ing you as well on bugs like this and bug 598834? I read all Canvas bug anyway; but I'm mostly useless on Canvas2D bugs.
Yeah, we really need it profiled in a build without omitted frame pointers so we can get some decent stack traces. It'd be interesting to know how much time is spent in JS related stuff. As from the things you posted it seems this is most likely JS bound. But there's not enough info to be sure.
Looking at this in Shark on Mac, it's not js-bound here (mostly in CoreGraphics). If it's not js-bound here, seems unlikely on Windows.
Still on Mac, main-thread time is about 51% FillText on the canvas and another 15% window painting. About 30% of the time is js engine, but 1/3 of this is realloc calls. For overall time, main thread is only about 88%. The remainder is about 3% video decoder thread and 8% GC thread calling free. That said, I see no lag at all. So if there's lag on Windows, I'd look at FillText first.
You need to log in before you can comment on or make changes to this bug.