Open
Bug 540066
Opened 14 years ago
Updated 1 year ago
Stroking with CoreGraphics appears to be slower than it needs to be
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
NEW
People
(Reporter: jrmuizel, Unassigned)
References
Details
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.
Comment 1•14 years ago
|
||
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.
Comment 2•14 years ago
|
||
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.
Comment 3•14 years ago
|
||
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.
Comment 5•14 years ago
|
||
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.
Comment 6•13 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 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.
Comment 7•13 years ago
|
||
Sorry, please disregard the previous comment. It was meant for another thread.
Reporter | ||
Comment 9•12 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.
Updated•2 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Component: Graphics → Graphics: Canvas2D
You need to log in
before you can comment on or make changes to this bug.
Description
•