- From: <bugzilla@jessica.w3.org>
- Date: Tue, 25 Oct 2011 04:23:35 +0000
- To: public-html-bugzilla@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