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: http://bocoup.com/core/code/strokes/stroke-speeds.html http://bocoup.com/core/code/strokes/stroke-speeds2.html http://weare.buildingsky.net/processing/test/strokeTest-unoptimized.html 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: http://bocoup.com/core/code/firefox-fft/canvas-gen-func.html
(In reply to comment #3) > See also this test where we get killed doing only stroke vs. chrome: > > http://bocoup.com/core/code/firefox-fft/canvas-gen-func.html 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.
Same happens with fill(), closePath() etc: http://bocoup.com/core/code/firefox-fft/canvas-fill.html http://bocoup.com/core/code/js-tests/canvas-close-path.html Supporting Vlad's suggestion.
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 http://corehtml5canvas.com/bugreports/firefox4/animation/images/example.html. 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: > > http://bocoup.com/core/code/firefox-fft/canvas-fill.html > http://bocoup.com/core/code/js-tests/canvas-close-path.html > > Supporting Vlad's suggestion.
Sorry, please disregard the previous comment. It was meant for another thread.
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.