920659 - Peacekeeper renderPhysics test slower than in Chrome

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

Attachment: renderPhysics.zip

Yet Another Peacekeeper Test. Original test here: http://www.peacekeeper.therichins.net/test3.html

I verified the numbers reported by the attached version match the original benchmark results in both Firefox and Chrome. The original test runs for 30 seconds.

Chrome 31: 78 fps
Nightly:   57 fps

Interestingly, the test has: 

    this.balls[i].style.MozTransform = "rotate(" + this.rotations[i] + "deg)"; 

And indeed, the "balls" (flowers) don't rotate in Chrome. Commenting out this line doesn't improve our score though.

I see some time in str_replace for calls like this:

    ball1.style.left.replace("px", "")

Will look closer into the JS stuff. bz, can you see what's going on on the DOM/layout side? Thanks!

Comment 1

[Boris Zbarsky [:bzbarsky]]

On the DOM/layout side I see this:

* 24% of the time is spent doing get_left and get_top.  That's fundamentally bug 608880.
  We should remeasure once bug 608915 lands.
* 8% is restyle processing.
* 16% is painting.

But note that those are percentages of _total_ time, across all threads.  About 25% of the time is on the compositor thread, so the above percentages should probably be higher.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I should also note that for me (on Mac), I see Chrome at about 70fps and a current nightly at 82fps.  If I apply the patch from bug 608915, we're at 85fps.

Comment 3

[Nathan Froyd [:froydnj]]

(In reply to Boris Zbarsky [:bz] from comment #2)
> I should also note that for me (on Mac), I see Chrome at about 70fps and a
> current nightly at 82fps.  If I apply the patch from bug 608915, we're at
> 85fps.

Is that with the ToShortest() patch or a different one?  (Nice to know it's still a speedup!)

Comment 4

[Boris Zbarsky [:bzbarsky]]

That's with the ToShortest() patch that's in that bug.

Comment 5

[Jan de Mooij [:jandem]]

(In reply to Boris Zbarsky [:bz] from comment #2)
> I should also note that for me (on Mac), I see Chrome at about 70fps and a
> current nightly at 82fps.  If I apply the patch from bug 608915, we're at
> 85fps.

You're right, I see the same here after updating my Nightly (also Mac). I will check if it's really a bug that landed the past few days...

Comment 6

[Guilherme Lima]

With a Nightly where bug 608915 I see 55 fps, while on Chrome 30 I see 64 fps.

Comment 7

[Guilherme Lima]

where bug 608915 is fixed*, sorry!

Comment 8

[Boris Zbarsky [:bzbarsky]]

On my hardware, on the testcase in this bug, I see Chrome at 60fp, while we're at 90fps.  Again, on Mac.

So it's possible that the remaining issues here are Windows-specific in some way...

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

On 64bit Linux Nightly 88fp, Chromium 110fp.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

On Win7 Nightly 57fps, Chromium 86fps.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Based on Gecko profiler, we spend more time inside refresh driver on Windows, if I interpret the profiler correctly. All about display list and rasterization.
Someone more knowledgeable about gfx could take a look.

Comment 12

[Benoit Girard (:BenWa)]

Maybe :bas wants to have a look if it's graphics that's holding us back on windows only.

Comment 13

[Bas Schouten (:bas.schouten)]

Is this still a problem and/or do we still care about this?

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

It is still a problem and we do still care.
On linux I see Nightly 73, Chromium 90

On Windows Nightly 58, Chrome 75

(Different Windows and Linux machines).

Comment 11 is still valid. And from comment 1, the part about bug 608880 is showing up still significantly.

Comment 15

[Bas Schouten (:bas.schouten)]

(In reply to Olli Pettay [:smaug] from comment #14)
> It is still a problem and we do still care.
> On linux I see Nightly 73, Chromium 90
> 
> On Windows Nightly 58, Chrome 75
> 
> (Different Windows and Linux machines).
> 
> Comment 11 is still valid. And from comment 1, the part about bug 608880 is
> showing up still significantly.

I'll have a look, obviously bug 608880 is not really in graphics domain. I'll have a look if there's actual graphics work here taking up significant time and being eligible for improvement.

Comment 16

[Bas Schouten (:bas.schouten)]

I should note my results on windows are different:

Firefox: 90
Chrome: 57
IE: 49
Edge: 47

Could you post your about:support graphics section?

Also, firefox seems to be the only browser where the seeds are also 'rotating' around. Is this correct?

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

Yeah, bug 608880 has nothing to do with graphics, but comment 11 is possibly. Though it is also about display list stuff.

My Windows laptop gfx:
    Adapter Description     Intel(R) HD Graphics 4000
    Adapter Drivers igdumdim64 igd10iumd64 igd10iumd64 igdumdim32 igd10iumd32 igd10iumd32
    Adapter RAM     Unknown
    Asynchronous Pan/Zoom   wheel input enabled; touch input enabled
    Device ID       0x0166
    Direct2D Enabled        true
    DirectWrite Enabled     true (10.0.10586.0)
    Driver Date     6-16-2015
    Driver Version  10.18.10.4242
    GPU #2 Active   false
    GPU Accelerated Windows 1/1 Direct3D 11 (OMTC)
    Subsys ID       00000000
    Supports Hardware H264 Decoding Yes; Using D3D11 API
    Vendor ID       0x8086
    WebGL Renderer  Google Inc. -- ANGLE (Intel(R) HD Graphics 4000 Direct3D11 vs_5_0 ps_5_0)
    windowLayerManagerRemote        true
    AzureCanvasAccelerated  0
    AzureCanvasBackend      direct2d 1.1
    AzureContentBackend     direct2d 1.1
    AzureFallbackCanvasBackend      cairo

Comment 18

[Bas Schouten (:bas.schouten)]

(In reply to Olli Pettay [:smaug] from comment #17)
> Yeah, bug 608880 has nothing to do with graphics, but comment 11 is
> possibly. Though it is also about display list stuff.
> 
> My Windows laptop gfx:
>     Adapter Description     Intel(R) HD Graphics 4000
>     Adapter Drivers igdumdim64 igd10iumd64 igd10iumd64 igdumdim32
> igd10iumd32 igd10iumd32
>     Adapter RAM     Unknown
>     Asynchronous Pan/Zoom   wheel input enabled; touch input enabled
>     Device ID       0x0166
>     Direct2D Enabled        true
>     DirectWrite Enabled     true (10.0.10586.0)
>     Driver Date     6-16-2015
>     Driver Version  10.18.10.4242
>     GPU #2 Active   false
>     GPU Accelerated Windows 1/1 Direct3D 11 (OMTC)
>     Subsys ID       00000000
>     Supports Hardware H264 Decoding Yes; Using D3D11 API
>     Vendor ID       0x8086
>     WebGL Renderer  Google Inc. -- ANGLE (Intel(R) HD Graphics 4000
> Direct3D11 vs_5_0 ps_5_0)
>     windowLayerManagerRemote        true
>     AzureCanvasAccelerated  0
>     AzureCanvasBackend      direct2d 1.1
>     AzureContentBackend     direct2d 1.1
>     AzureFallbackCanvasBackend      cairo

Hrm, this is interesting, I'm also on D2D 1.1 and Intel HD graphics (although 5000 series), but I'm seeing way better performance on Firefox than on Chrome. Are you seeing the seeds rotating on chrome at all?

Comment 19

[Bas Schouten (:bas.schouten)]

Hrm, so on another machine, I do get slightly better perf on Chrome, however on Firefox the dandelion seeds are rotating and on chrome they're not.... what's the right behavior?

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

oh, indeed they are not rotating in chrome, nor in Edge. (looks like Edge is quite slow here.)
Let me check how to prevent rotating in FF too and then do comparison.

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

Commenting this.balls[i].style.MozTransform = "rotate(" + this.rotations[i] + "deg)"; out seems to be enough. On linux Nightly 99, Chrome 90. On Windows Nightly 58, Chrome 89, Edge 19. 
(My linux machine is significantly more powerful than the Windows one)