This is a silly performance test, but Safari is quite slow. TESTCASE http://hixie.ch/tests/adhoc/perf/video/002.html
I would say these are more "edgecase" or "minor performance complaints" instead of "serious performance complaints". P3 http://webkit.opendarwin.org/quality/bugpriorities.html
Assigning bugs which hyatt is not actively working on to "nobody" for clarity/consistancy.
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.
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?
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.
Comment on attachment 26311 [details] First step of fixing -- coalesce dirty rects to amortise calls to repaint looks good
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
Created attachment 26334 [details] Use fast path color parsing Make use of the faster colour parsing routines of the Color class
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.
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
How about fixing incremental repaints in canavs?
Sharking shows that the Font copying (bug 23050) affects this too.
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.
I filed bug 23110 to optimize rbg() and rgba() color parsing.
For CG and Qt, the patch in bug 42088 likely helps with this.
More helpful stuff: bug 42267
Do we have an up to date sample of this?
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 ~:"
#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 ?
filed as bug82147
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!
Seems unlikely that this test will drive more improvements, but folks can reopen if there is renewed interest.