- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Sat, 16 Feb 2013 22:12:02 +1300
- To: Stephen White <senorblanco@chromium.org>
- Cc: whatwg@whatwg.org, Ian Hickson <ian@hixie.ch>, Rik Cabanier <cabanier@gmail.com>
On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco@chromium.org>wrote: > deferred canvas rendering (collect commands into a buffer, flush buffer > only when compositing canvas to page, and decide on subpixel AA at that > point) > pro: catches all cases of color fringing > con: in some cases, requires an infinite buffer (e.g., a canvas that > never clears, and only accumulates drawing frame-to-frame means you must > accumulate commands indefinitely) > con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc) > con: may introduce performance hit due to re-rendering with and without > subpixel AA (in cases where you would rather have just gone without) > > two buffers (one grayscale, one LCD AA) > pro: handles all cases of color fringing > pro: moderately easy to implement > con: RAM (or VRAM) usage is doubled > con: possibly-unnecessary performance hit > con: must be opt-in > Both of these schemes can actually be optimized some more: As long as no text is drawn to a canvas, you can freely rasterize (in the first case) or use just one buffer (in the second case). In fact, this is true as long as no text is drawn to a canvas over non-opaque pixels. So a lot of canvas usage could be handled with little or no performance hit. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Received on Saturday, 16 February 2013 09:12:26 UTC