W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[Bug 14499] Need ability to reset Canvas clipping region without resetting all other Canvas state

From: <bugzilla@jessica.w3.org>
Date: Tue, 25 Oct 2011 04:23:35 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RIYY3-0005JE-Ue@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14499

--- Comment #4 from Simon Sarris <simon.sarris@gmail.com> 2011-10-25 04:23:35 UTC ---
If one wants to make heavy use of clipping, one cannot (as effectively as one
would like) cache attributes, with font being the one of the biggest offenders.
(Caching other attributes leads to non-trivial performance gains too).

That kind of scenario comes up when you have complex panels, for example in a
diagramming app where a parent panel may arrange and clip child panels, which
may in turn arrange and clip text strings and other objects.

Here is a distilled working example of why one loses the ability to cache font
in such a scenario:

http://jsfiddle.net/PwAGz/

Having no way to reset the clipping region makes these kind of optimizations
harder when you do have a scenario such as nested-and-clipped objects.

Setting the font is very slow in some browsers. For just how big of an offender
it is, here's a simple test of fillText vs setting font + fillText:

http://jsperf.com/set-font-perf

In short, having to set the font each time is:

- 14% slower on Firefox

- 57% slower on Chrome 16 (dev and nightly). That is to say, if you do not set
the font, then execution is more than twice as fast.

- About the same on IE9

I have mentioned that font is not the only thing that results in non-trivial
performance gains when cached. If these performance hits alone are not enough
to cause you to consider having some kind of resetClip(), I can provide more
evidence.

Thank you.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 25 October 2011 04:23:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:06 UTC