1,295
edits
(→API) |
No edit summary |
||
| Line 1: | Line 1: | ||
= Gecko Needs = | = Gecko Needs = | ||
== Semantics == | === Semantics === | ||
The basics of cairo's semantics seem to be OK --- fill path/stroke path/showglyphs, with source patterns, destination surfaces, operators, etc. | The basics of cairo's semantics seem to be OK --- fill path/stroke path/showglyphs, with source patterns, destination surfaces, operators, etc. | ||
| Line 10: | Line 10: | ||
* Allowing changes to the CTM during path emission is useless for us | * Allowing changes to the CTM during path emission is useless for us | ||
== API == | === API === | ||
Gecko doesn't make much use of the statefulness of contexts. Every time we draw a display item, we reset most of the state. The exceptions are clipping and transforms. (But we often do need to be able to reset clipping to a given clipping state.) | Gecko doesn't make much use of the statefulness of contexts. Every time we draw a display item, we reset most of the state. The exceptions are clipping and transforms. (But we often do need to be able to reset clipping to a given clipping state.) | ||
| Line 36: | Line 36: | ||
= Proposal = | = Proposal = | ||
== API == | === API === | ||
Stateful abstractions are a pain because we reset them a lot anyway and mapping one stateful abstraction onto another is tricky where they don't quite match up (e.g. semantics of changing the transform while emitting a path). | Stateful abstractions are a pain because we reset them a lot anyway and mapping one stateful abstraction onto another is tricky where they don't quite match up (e.g. semantics of changing the transform while emitting a path). | ||
| Line 52: | Line 52: | ||
Provide explicit API for fillRect and other canvas operations so we don't have to waste time in backends identifying which fast path to use having gone through a generic path operation. | Provide explicit API for fillRect and other canvas operations so we don't have to waste time in backends identifying which fast path to use having gone through a generic path operation. | ||
== Implementation == | === Implementation === | ||
For optimal efficiency with stateful backends we need to figure out what state needs to be updated at each drawing call and only update that state. For example, with Quartz, if the operator, antialiasing mode, clip and source pattern are the same as the previous drawing call, we shouldn't do Quartz calls to set them. Packing flags and modes into a single flags word will help quick identification of changes. We'll want to be able to identify reused clips and source patterns efficiently without making those objects too heavyweight. This may require some ingenuity. | For optimal efficiency with stateful backends we need to figure out what state needs to be updated at each drawing call and only update that state. For example, with Quartz, if the operator, antialiasing mode, clip and source pattern are the same as the previous drawing call, we shouldn't do Quartz calls to set them. Packing flags and modes into a single flags word will help quick identification of changes. We'll want to be able to identify reused clips and source patterns efficiently without making those objects too heavyweight. This may require some ingenuity. | ||
=== Plan Of Attack === | |||
Start with canvas. We have performance needs there, the risk is lower and the implementation burden is lower. | |||
* Implement new gfx API as a wrapper around cairo | |||
* Clone nsCanvasRenderingContext2D with a run-time switch to use new implementation | |||
* New Context2D uses new gfx API | |||
** At this point we have something that works and we can iterate on the gfx API | |||
* Implement new D2D and/or Quartz backends | |||
** At this point we should have significant performance wins on real Web apps and something we want to ship | |||
* Implement GL backend (lots more work) | |||
* On a branch: | |||
** Reimplement gfxContext on top of new gfx API | |||
** Incrementally convert all our graphics code to the new API | |||
** Land | |||
edits