Re: [whatwg] Enabling LCD Text and antialiasing in canvas

On Sat, Nov 24, 2012 at 7:10 PM, Adam Barth <w3c@adambarth.com> wrote:
> 2) Remarkably, the current best candidate is a rendering pipeline that
> attempts to use the DOM in immediate mode.  The application performs
> some application-specific processing to determine which portions of
> the model can actually affect what's drawn on screen, and then the
> application uses innerHTML to create DOM for that portion of the
> model.  (They've experimented with a bunch of choices and innerHTML
> appears to be the fastest way to use the DOM as an immediate mode
> API.)  Using this pipeline, the application uses reasonable amounts of
> memory and hit testing, etc, aren't impacted.  This pipeline gets
> about 20 fps.

I'm working on ways to make this process easier and more performant,
first on the CSS side, then on the DOM side.  Right now it's internal,
but as soon as I have something that's not crap, I'll be posting it
here for review, feedback, and iteration.

My current plan is:

* On the CSS side, provide some nice new primitives for "isolating"
layout of elements, so that you can be sure that your DOM-tweaking
won't break out and cause unexpected reflow in the rest of the
document.  That's a perf-killer.  Connected to that, provide a way to
guarantee that an element's rendering doesn't extend outside of itself
(or a bounds around itself), so that we can, behind the scenes,
destroy renderers that are off-screen and which we predict won't be
viewed again in the near future.

* On the DOM side, at the lowest level, provide some primitives that
do the ugly grunt-work that people are already doing in JS (prediction
of the area that is visible and which is soon-to-be-visible), and
hopefully neuter some related problems of very large lists as well
(such as simply running out of coordinate space - it appears that you
start hitting problems when an element exceeds 1M-16M (varies by
browser) pixels in one dimension).  Building atop that, some
convenient declarative tools that take even more of the work out of
the author's hands and let us do more stuff automatically and with
higher performance: for example, perhaps the author can just provide a
JS array of data and a <template> element, and the browser generates
and destroys DOM on the fly from this.

~TJ

Received on Monday, 26 November 2012 17:58:09 UTC