Mozilla2:GFXEvolution: Difference between revisions

← Older edit

Mozilla2:GFXEvolution (view source)

Revision as of 04:28, 29 March 2007

77 bytes added , 29 March 2007

m

no edit summary

Taken

151

edits

@@ Line 1: / Line 1: @@
-Here's a plan I suggested for how to do this work. Various parts are controversial (hello vlad!).
+''This was the plan in 2005''; see [[Mozilla2:GraphicsPlan]] for actual development in 2006.
-. Get gfx/cairo (an implementation of our current gfx interfaces based on Cairo) into working order.
+Some can be done in parallel.
-. 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.
-. 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 (i.e. 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.
-. 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 those are 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.
+# Wrap [http://cairographics.org cairo] in "Thebes", 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.
+# Get gfx/cairo (an implementation of our current gfx interfaces based on Thebes) into working order.
+# 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 favor of using gfx/cairo on the platform. Ideally we'll end up with just gfx/cairo and possibly some gfx implementation for embedded devices.
+# 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.