Stroking with CoreGraphics appears to be slower than it needs to be




9 years ago
7 years ago


(Reporter: jrmuizel, Unassigned)


1.9.2 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)




9 years ago
There are profiles where we spend 13% in cairo_stroke but only 5.6% in CGContextStrokePath.

Humph can perhaps come up with a demo that shows this.
Corban/Al have some code we use to visualize fft audio data that does heavy line drawing.  Maybe they can do a version that doesn't rely on the audio patch and people can test?  CC'ing them.
I'm having a hard time reproducing exactly as we saw the other day, but we did throw together some tests of stroke and path code, see:

Most of what I'm seeing with these is time in CoreGraphics (sometimes as high as ~45% total), but I'll keep trying to give you a test that shows what we saw.
See also this test where we get killed doing only stroke vs. chrome:
(In reply to comment #3)
> See also this test where we get killed doing only stroke vs. chrome:

That should probably be a different bug, not sure if it's the same as this -- that benchmark doesn't create a path, so it's essentially benchmarking pure js, xpconnect, and cairo_stroke() with-no-path overhead.  Useful thing to fix for sure, but not sure if it's the same issue.

Comment 6

8 years ago
I don't think any of that is an issue. I changed the example so that it only does two things during the animation: context.clearRect() and context.drawImage(). I still get choppy animation. You can try it at

With Minefield, something is awry: the images leave considerable residue on the canvas as they animate. I don't see that problem with FF4.

I will send Boris a profile of the new example.

(In reply to comment #5)
> Same happens with fill(), closePath() etc:
> Supporting Vlad's suggestion.

Comment 7

8 years ago
Sorry, please disregard the previous comment. It was meant for another thread.
Duplicate of this bug: 631211

Comment 9

7 years ago
This is much better now that bug 692879 has landed. There's still room for improvement here though. We spend a bunch of time in CGColorCreate that Safari doesn't. We also do more CGContextSave and CGContextRestore than Safari does.
You need to log in before you can comment on or make changes to this bug.