Open Bug 599954 Opened 9 years ago Updated 5 years ago

Chrome Experiments : Swirling Tentacles is super slow due to using "with"

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: cldenobrega, Unassigned)

References

()

Details

(Whiteboard: [chromeexperiments])

Attachments

(2 files)

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
Whiteboard: [chromeexperiments]
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file Swirling Arms Hotspots
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
Component: Graphics → JavaScript Engine
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
blocking2.0: ? → -
status2.0: --- → wanted
Still very slow on Win7 w/ D2D and JM+TI.
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.