Open Bug 919992 Opened 8 years ago Updated 7 years ago

Peacekeeper ripple tests slower than in Chrome

Categories

(Core :: Canvas: 2D, defect)

defect
Not set
normal

Tracking

()

People

(Reporter: jandem, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file)

Attached file Testcase
I'm attaching a standalone, reduced version of http://www.peacekeeper.therichins.net/test12.html

I get 18-19 fps on OS X. With Chrome 31 it's 30-31 fps.

On the JS side, we seem to spend a lot of time in js_math_round; we should find out why we're not inlining that. However, JS seems to be faster than Chrome already (see also bug 606648).

It looks like we need to make this faster:

    this.ctx.fillStyle = "rgb("+rValue+", "+gValue+", "+bValue+")";
    this.ctx.fillRect(this.xPosition + x * this.pixelWidth, 
                      this.yPosition + y * this.pixelHeight,  
                      this.pixelWidth,
                      this.pixelHeight);

We seem to spend a lot of time under fillRect and parsing "rgb(..)". Filing this bug in the CSS component but maybe Canvas/Graphics is a better choice; feel free to move it.
Depends on: 920046
Bug 920046 will make the Math.round call a good bit faster. With that most of the JS time will be in JIT code and math_round_impl/floor and we are a lot faster than V8.

If we can be as fast as Chrome on the canvas stuff we will do really well on this test.
For fillRect, see bug 601176.

I could have sworn we had existing bugs about color parsing.... I'll see what's going on there.
Component: CSS Parsing and Computation → Canvas: 2D
Depends on: 601176
So for what it's worth, I just tried this on Mac.  The testcase is about 20fps for me, with Chrome at 30fps.

If I comment out the fillRect call, we're at 85-90 fps, while Chrome is at 65-70.

So the non-fillrect bits of this take at most 12ms for us (of which a profile says about half is color parsing), while fillRect takes about 40ms.  For Chrome, the non-fillRect bits take about 14ms, and the fillRect takes about 20ms.

So this is really fillRect-bound.  I'll see what I can do about shaving time off color parsing but even if that gets down to 0 we'll end up at 22fps.
Profile shows nothing really obvious for color parsing other than "it's complicated".  Which it is.  :(
Yeah, the place to look is to figure out the fillRect cost.  Color parsing sucks, I've long advocated that we should accept arrays to fillColor/strokeColor too (e.g. canvas.fillColor = [1.0, 0.0, 0.0, 1.0]; for rgba) to entirely skip the parsing.
One day we might want a supermagical WebIDL extension such as
  [StringSetter(fillStyleRGB, "rgb(", unsigned long r, ",", unsigned long g, ",", unsigned long b, ")"),
   StringSetter(fillStyleRGBA, "rgba(", unsigned long r, ",", unsigned long g, ",", unsigned long b, ",", float a, ")")]
  attribute (DOMString or CanvasGradient or CanvasPattern) fillStyle;
which could pattern-match JS expressions in the JIT and call through to special stubs, avoiding building the string and parsing it :-). Would also be useful for "element.style.top = y + 'px';" and stuff like that --- very common.
I just tested this one, and Nightly is faster than Chrome 33 (18 vs 16fps) on the testcase attached and on the original peacekeeper test.
On 64 bit Linux Nightly ~33fps vs Chromium ~21fps
You need to log in before you can comment on or make changes to this bug.