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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14499

--- Comment #6 from Simon Sarris <simon.sarris@gmail.com> 2011-10-25 17:19:11 UTC ---
The performance problem here is not about setting a font to an already-set
value. That's easy for programmers to remedy by checking and having a no-op, as
my example code already does.

The problem is not something browsers can currently fix. The context's font
starts at value "A" and gets set to a value "B" inside a nested series of
clipped objects. Then the panel housing the text object has restore() called
because there is no other way to grow the clipping region, and so the font
becomes "A" again. It would be nice if it could remain "B" so that one would
not be required to set the font again, because perhaps the next 500 text
objects to be drawn (which are nested in clipped panels) have the "B" font. The
example shows how keeping the ctx.font "B" is not possible if you have nested
objects clipping.

For the record, what I am doing is creating a professional diagramming library
that supports greater than 10,000 nodes and links of different complexities,
with layouts and animation and other bells and whistles. The performance is
very good, much better than similar products out for canvas (so far), and the
kind of performance I have is not possible if I use SVG or HTML/CSS to do it,
as 10,000 DOM elements is a performance nightmare from the get-go! My nodes can
contain any number of nested panels and any of these can have a maximum size,
which might necessitate clipping their children in some way. Thus this problem
arises. I'm sure there are other real-world examples of successive clipping
used in such a way that disallow effective property caching.

Over the past year I have amassed a large number of canvas performance findings
(I've blogged a few of them) that have allowed me to create fast canvas apps.
In the future hope to publish them and dispel the notion that canvas is
necessarily too slow. This issue at hand is one of the few problems that have
no programmatic remedy except to avoid several potentially legitimate uses of
clipping.

It is important to remember here that font is merely an example as it is just
one of the properties that resetting a clipping region will clear. In general I
think we should consider it a bad thing that there is simply no way to reset a
clipping region without also resetting the whole state of the canvas. That
performance can suffer so much because of it only compounds the problem.

Adding a resetClip or setClip or similar method would also be more in line with
the rest of the context's functionality. After all, one is able to reset the
transform, or indeed anything else without having to reset the rest of the
context state. Why shouldn't the same be possible with a clipping region?

-- 
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 17:19:18 UTC