Mozilla2:GFXEvolution: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(added SVG links)
No edit summary
Line 2: Line 2:


# Get gfx/cairo (an implementation of our current gfx interfaces based on [[Cairo]]) into working order.
# Get gfx/cairo (an implementation of our current gfx interfaces based on [[Cairo]]) into working order.
# gfx/cairo exposes thin C++ wrappers over [[Cairo]] APIs which can be used by advanced rendering customers --- [[SVG]], view manager --- when gfx/cairo is in use.
# gfx/cairo exposes thin [[Mozilla2:NewGFXAPIs|C++ wrappers]] over [[Cairo]] APIs which can be used by advanced rendering customers --- [[SVG]], view manager --- when gfx/cairo is in use.
# Work on gfx/cairo performance until it performs as well as gfx/win, gfx/mac and gfx/gtk on our normal Web workloads on modest machines (e.g., without GPUs). Will require significant work on [[Cairo]] itself.
# Work on gfx/cairo performance until it performs as well as gfx/win, gfx/mac and gfx/gtk on our normal Web workloads on modest machines (e.g., without GPUs). Will require significant work on [[Cairo]] itself.
# Wherever possible, drop platform gfx implementations in favour of using gfx/cairo on the platform. Ideallly we'll end up with just gfx/cairo and possibly some gfx implementation for embedded devices.
# Wherever possible, drop platform gfx implementations in favour of using gfx/cairo on the platform. Ideallly we'll end up with just gfx/cairo and possibly some gfx implementation for embedded devices.

Revision as of 21:35, 12 March 2005

Here's a plan I suggested for how to do this work. Various parts are controversial (hello vlad!). Some can be done in parallel.

  1. Get gfx/cairo (an implementation of our current gfx interfaces based on Cairo) into working order.
  2. gfx/cairo exposes thin C++ wrappers over Cairo APIs which can be used by advanced rendering customers --- SVG, view manager --- when gfx/cairo is in use.
  3. Work on gfx/cairo performance until it performs as well as gfx/win, gfx/mac and gfx/gtk on our normal Web workloads on modest machines (e.g., without GPUs). Will require significant work on Cairo itself.
  4. Wherever possible, drop platform gfx implementations in favour of using gfx/cairo on the platform. Ideallly we'll end up with just gfx/cairo and possibly some gfx implementation for embedded devices.
  5. With only one or two gfx implementations to deal with, clean up the legacy gfx interfaces, either by moving functionality to the new API wrappers, or by modifying the legacy interfaces in place.

The goal here is to be incremental but also tackle the riskiest, most questionable issues as early as possible (IMHO getting Cairo to perform well on our platforms and workloads). Also as soon as we complete step 2 we can work on rich SVG/HTML/XUL integration with a unified rendering pipeline. Getting super-cool demos working soon is very important.