Canvas:1.8 Branch

From MozillaWiki
Jump to: navigation, search

1.8 Branch Canvas changes/updates

canvas is a very rich tool for web developers; we should optimize it for Fx2, and not ask people to wait for Fx3 to see improvements over 1.5. In addition, we should make it possible to do fast pluggable contexts as extensions.

In the current canvas implementation, the <canvas> keeps an image (software-only) surface in memory; it updates a nsIImage buffer with this data when its needed (assuming the cairo image surface changed). Then, that's rendered into a nsIRenderingContext, and is blended using nsBlender. This is pretty much abysmal for performance.

What I'd like to do is: pass the nsIRenderingContext (gfxContext* on the trunk/thebes) directly to each canvas context from the frame's Draw call. So, would go something like frame::draw -> canvasElement::drawContexts -> context1::draw, context2::draw, etc. This removes the intermediate image surface copy. The second thing is to create and use native surfaces for the canvas back buffer -- this gives us fast blits and accelerated operations.

To-do List

Canvas 1.8.1

  • needs write-only pull-up from trunk
  • needs toDataURL pull-up from trunk
  • nsICanvasElement
    • add RenderContexts (nsIRenderingContext *ctx)
    • remove GetCanvasImageContainer
  • nsICanvasRenderingContextInternal
    • add Render (nsIRenderingContext *ctx)
    • remove UpdateImageFrame
  • update cairo from trunk (need version tagged in git)
    • needs ifdefs to remove font stuff, since it depends on stuff that's not used for 1.8 (win2k glyph stuff, pango)
    • needs symbol renaming in on both branch and trunk!!!
    • needs more work on quartz surface, but not much -- we can use fallback since we'll always use a CGImage
  • need a mozcairo.dll on 1.8, that extensions can hook into
    • talk to me: why do we need glitz for this? -- shaver er, we don't, too many comingling plans on my part -- vlad
    • need to take glitz on 1.8 and build it into mozcairo.dll
      • needs runtime linking to libGL, not dynamic