Bug 3781 - Animation via canvas could be faster
Summary: Animation via canvas could be faster
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 412
Hardware: PC OS X 10.4
: P1 Normal
Assignee: Oliver Hunt
URL: http://hixie.ch/tests/adhoc/perf/vide...
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-30 14:27 PDT by Ian 'Hixie' Hickson
Modified: 2012-03-25 10:28 PDT (History)
9 users (show)

See Also:


Attachments
First step of fixing -- coalesce dirty rects to amortise calls to repaint (2.70 KB, patch)
2008-12-30 03:50 PST, Oliver Hunt
no flags Details | Formatted Diff | Diff
Use fast path color parsing (2.80 KB, patch)
2008-12-31 04:24 PST, Oliver Hunt
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ian 'Hixie' Hickson 2005-06-30 14:27:58 PDT
This is a silly performance test, but Safari is quite slow.

TESTCASE
   http://hixie.ch/tests/adhoc/perf/video/002.html
Comment 1 Eric Seidel (no email) 2005-07-03 17:11:10 PDT
I would say these are more "edgecase" or "minor performance complaints" instead of "serious performance 
complaints".

P3

http://webkit.opendarwin.org/quality/bugpriorities.html
Comment 2 Eric Seidel (no email) 2005-12-27 13:29:37 PST
Assigning bugs which hyatt is not actively working on to "nobody" for clarity/consistancy.
Comment 3 Alexey Proskuryakov 2007-05-01 03:11:30 PDT
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.
Comment 4 Oliver Hunt 2008-12-29 04:01:28 PST
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?
Comment 5 Oliver Hunt 2008-12-30 03:50:24 PST
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 6 Antti Koivisto 2008-12-30 04:14:37 PST
Comment on attachment 26311 [details]
First step of fixing -- coalesce dirty rects to amortise calls to repaint

looks good
Comment 7 Oliver Hunt 2008-12-30 04:19:46 PST
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
Comment 8 Oliver Hunt 2008-12-31 04:24:04 PST
Created attachment 26334 [details]
Use fast path color parsing

Make use of the faster colour parsing routines of the Color class
Comment 9 Cameron Zwarich (cpst) 2008-12-31 04:26:02 PST
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 10 Oliver Hunt 2008-12-31 04:32:23 PST
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
Comment 11 Simon Fraser (smfr) 2008-12-31 09:36:10 PST
How about fixing incremental repaints in canavs?
Comment 12 Simon Fraser (smfr) 2008-12-31 10:02:30 PST
Sharking shows that the Font copying (bug 23050) affects this too.
Comment 13 Simon Fraser (smfr) 2009-01-01 19:45:25 PST
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.
Comment 14 Simon Fraser (smfr) 2009-01-04 17:03:13 PST
I filed bug 23110 to optimize rbg() and rgba() color parsing.
Comment 15 Andreas Kling 2010-07-14 06:25:44 PDT
For CG and Qt, the patch in bug 42088 likely helps with this.
Comment 16 Andreas Kling 2010-07-14 09:30:36 PDT
More helpful stuff: bug 42267
Comment 17 Oliver Hunt 2011-04-17 18:21:30 PDT
Do we have an up to date sample of this?
Comment 18 jay 2012-03-24 22:59:36 PDT
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 ~:"
Comment 19 jay 2012-03-25 00:20:29 PDT
#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 ?
Comment 20 jay 2012-03-25 10:28:03 PDT
filed as bug82147