Bug 3781 – Animation via canvas could be faster

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Layout and Rendering

[Ian 'Hixie' Hickson]

This is a silly performance test, but Safari is quite slow.

TESTCASE
   http://hixie.ch/tests/adhoc/perf/video/002.html

[Eric Seidel (no email)]

I would say these are more "edgecase" or "minor performance complaints" instead of "serious performance 
complaints".

P3

http://webkit.opendarwin.org/quality/bugpriorities.html

[Eric Seidel (no email)]

Assigning bugs which hyatt is not actively working on to "nobody" for clarity/consistancy.

[Alexey Proskuryakov]

On my machine (G4/1.25DP), this test is far from ideal in a recent nightly at ~2.2fps, but Firefox and Opera are still worse.

[Oliver Hunt]

This testcase actually just points out the major problems with fillRect drawing in canvas, some quick sharking shows two immediate problems
1) HTMLCanvasElement::willDraw takes 40% of the runtime -- note that painting only takes 11% of the time.   We should be able to reduce this a wee bit.
2) Parsing the colors takes 20% of the runtime -- instantiating full CSSParser every time, then tearing it back down.  We have fast pass parsers, so why aren't we using them?

[Oliver Hunt]

Created attachment 26311 [details]
First step of fixing -- coalesce dirty rects to amortise calls to repaint

Coalesce the dirty region repaints a later patch can remove direct calls to repaint in favour of a single call per dirty canvas at mthe end of js execution.

[Antti Koivisto]

Comment on attachment 26311 [details]
First step of fixing -- coalesce dirty rects to amortise calls to repaint

looks good

[Oliver Hunt]

Comment on attachment 26311 [details]
First step of fixing -- coalesce dirty rects to amortise calls to repaint

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	WebCore/ChangeLog
	M	WebCore/html/HTMLCanvasElement.cpp
	M	WebCore/html/HTMLCanvasElement.h
Committed r39518

[Oliver Hunt]

Created attachment 26334 [details]
Use fast path color parsing

Make use of the faster colour parsing routines of the Color class

[Cameron Zwarich (cpst)]

Comment on attachment 26334 [details]
Use fast path color parsing

In applyStrokeColor, you add a blank line after your new code. In applyFillColor, you don't. Pick one and be consistent. ;-)

Otherwise, r=me.

[Oliver Hunt]

Comment on attachment 26334 [details]
Use fast path color parsing

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	WebCore/ChangeLog
	M	WebCore/html/CanvasStyle.cpp
Committed r39526

[Simon Fraser (smfr)]

How about fixing incremental repaints in canavs?

[Simon Fraser (smfr)]

Sharking shows that the Font copying (bug 23050) affects this too.

[Simon Fraser (smfr)]

Parsing rgb() colors is still a significant cost in some examples, e.g. http://www.bel.fi/~alankila/plasma.html in "compatible" mode. Shark shows 35% of the time in color parsing.

[Simon Fraser (smfr)]

I filed bug 23110 to optimize rbg() and rgba() color parsing.

[Andreas Kling]

For CG and Qt, the patch in bug 42088 likely helps with this.

[Andreas Kling]

More helpful stuff: bug 42267

[Oliver Hunt]

Do we have an up to date sample of this?

[jay]

testcaase: http://www.peepo.com
click on board,
if rendering bug is not evident,
adjust speed, in bottom left repeatedly click on thinking symbol to make slower,
ie more animated colour.

in my tests only a maximum 6-8 square inches gets rendered,
as a partial irregular box, from top left corner

firefox renders smoothly at all speeds, on 2.26 Ghz core2duo

bilinear lerp is used to generate large colour map.
can file as separate bug as required.
please indicate what and where ~:"

[jay]

#18

oops, you will also need to enable mcts animation,
click on golden key and tick mcts.

similar code is used to render
http://localhost/talks/mcts.html
but that renders well in recent safari

so maybe related to bug68635 ?

[jay]

filed as bug82147

[Ahmad Saleem]

Created attachment 459896 [details]
Safari 15.5 is faster than other browsers

I think in today's browser war - Safari / Webkit is still doing better than competitors on macOS 12.4 (M1 Pro) chip as shown in the picture. All related optimisation bugs are also fixed in the last few comments. Should we close this unless if there are more optimization in pipeline? Thanks!

[Alexey Proskuryakov]

Seems unlikely that this test will drive more improvements, but folks can reopen if there is renewed interest.