Chrome Experiment "Video->ASCII" slower than in Chrome at higher resolutions

NEW
Unassigned

Status

()

Core
Canvas: 2D
8 years ago
8 years ago

People

(Reporter: Steven, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [chromeexperiments], URL)

Attachments

(4 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.13) 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.
(Reporter)

Comment 1

8 years ago
Created attachment 478175 [details]
CPU profiling within xul.dll
(Reporter)

Updated

8 years ago
Summary: Chrome Experiment "Video->ASCII" slower than Chrome at higher resolution → Chrome Experiment "Video->ASCII" slower than in Chrome at higher resolutions
Whiteboard: [chromeexperiments]
(Reporter)

Comment 2

8 years ago
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            8.17.12.5896
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.
(Reporter)

Comment 5

8 years ago
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.
(Reporter)

Comment 6

8 years ago
Created attachment 478583 [details]
Overall CPU Profiling

The top section "Unknown" is collapsed for brevity, it contains calls made to NVidia graphics card drivers.
(Reporter)

Comment 7

8 years ago
Created attachment 478584 [details]
CPU Profiling within DWrite.dll
(Reporter)

Comment 8

8 years ago
Created attachment 478585 [details]
CPU Profiling within d2d1.dll
(Reporter)

Updated

8 years ago
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.