Open Bug 599954 Opened 9 years ago Updated 5 years ago
Chrome Experiments : Swirling Tentacles is super slow due to using "with"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100927 Firefox/4.0b7pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100927 Firefox/4.0b7pre Chrome Experiment : Swirling Tentacles displays a black window when started up in Minefield. Nothing shows up. When gfx.direct2d.force-enabled is set to false, Swirling Tentacles will show up in the browser, but is extremely slow and choppy. When the window is resized, the computer freezes. In Chromium, when the window is resized, swirling tentacles fits to the new size of the window. In Minefield, resizing the window produces scroll bars to the right and bottom of the window; swirling tentacles does not change to fit the window. Reproducible: Always Steps to Reproduce: 0. about:config preference gfx.direct2d.force-enabled is set to true. 1. Launch Chrome Experiment: Swirling Tentacles. 2. Notice a black window with nothing in it. 3. about:config set gfx.direct2d.force-enabled to false. 4. Restart browser. 5. Launch Experiment again. 6. Notice the slowness... 7. Try to resize the window. Actual Results: At step 1, nothing appears. At step 5, slow and choppy Swirling Tentacles show up. At step 7, computer freezes. Expected Results: The experiment should look the same as it does when viewed with Google Chromium. Swirling Tentacles should move fast and look smooth. Graphics Card Info: Adapter Description: AMD M880G with ATI Mobility Radeon HD 4200 Vendor ID: 1002 Device ID: 9712 Adapter: RAM336Adapter Drivers: atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Driver Version: 8.632.0.0 Driver Date: 7-2-2009 Direct2D Enabled: false DirectWrite Enabled: false GPU Accelerated Windows: 1/1 Direct3D 9
That "nothing shows up" business sounds like a blocker to me...
blocking2.0: --- → ?
Component: Canvas: 2D → Graphics
QA Contact: canvas.2d → thebes
(In reply to comment #1) > That "nothing shows up" business sounds like a blocker to me... I should not it's working fine for me and is pretty smooth. I can confirm it's superslow without D2D though.
It's -super- slow in Chromium with Accelerated Canvas. But it's smoother in normal chromium than with D2D on m-c though. Investigating the with-D2D case.
Latest trunk build for Windows 7: I see the animation at an OK speed without HA. With HA enabled (via the options) I do not see anything at all.
Hrm, I restarted my build and it now reproduces the D2D problem described above, i.e. a black screen. Investigating that too.
So the key to why this is not working appears to be the usage of globalCompositeOperation="lighter", or operator add. I'm still trying to figure out why it's not working, but I can confirm it works with the default composite operator.
So, there's two bugs here atleast: - There's a bug in D2D, I'll raise a separate bug on this and fix it there. - When using OPERATOR_OVER, this still runs a lot slower than in chromium. The majority of our time in this demo is spent in JS related stuff, we can see the JIT call into stroke and we can see that take up some significant amount of time (over 10%), but the vast majority seems to be spent in JS internals which I don't pretend to understand.
On my machine, we're at about 70ms per frame. Chrome is at 53, Opera at 45, Safari at 30. Anything over 33ms per frame will be "laggy" compared to perfect.
Looking at the code shows the obvious: global var (undeclared at that) access, and with. A profile (on Mac) says: 10% painting 4% in mjit-generated code 33% under stubs::Name, almost all under with_LookupProperty. This lands us in XPC_WN_ModsAllowedProtoResolve, XPC_WN_Helper_NewResolve, PropertyTable::search, hashtable ops, js_StartResolving, XPCCallContext construction for those XPConnect resolve hooks, etc. 20% under Stroke() on the canvas. 15% under stubs::CallName, which lands us in with_LookupProperty 9% under stubs::BindName, which lands us ... guess where ... via js_FindIdentifierBase. 4% under stubs::SetName<0> mostly setting style on the canvas. 2% ClearRect on the canvas. So the upshot is that with_LookupProperty is taking about 57% of the time here. We could try to make the xpconnect parts of that fast, but we really need to propcache or PIC or trace or _something_ our way to victory here. What does JSC do? Bas said he'll file a separate bug about not working with D2D enabled and comment here with the bug number.
Assignee: nobody → general
OS: Windows 7 → All
QA Contact: thebes → general
Hardware: x86_64 → All
Summary: Chrome Experiments : Swirling Tentacles only works with D2D disabled; is super slow → Chrome Experiments : Swirling Tentacles is super slow due to using "with"
D2D portion of this bug is in bug 600045. Please note this should be tested without operator lighter or without D2D to get a good JS performance profile. Operator lighter currently uses a lot of CPU on D2D.
Depends on: 600045
Still very slow on Win7 w/ D2D and JM+TI.
You need to log in before you can comment on or make changes to this bug.