Confirmed users
856
edits
Gecko:2DGraphicsThoughts: Difference between revisions
no edit summary
No edit summary |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 9: | Line 9: | ||
* Mask-based complex clipping is really slow and therefore pointless | * Mask-based complex clipping is really slow and therefore pointless | ||
* Allowing changes to the CTM during path emission is useless for us | * Allowing changes to the CTM during path emission is useless for us | ||
* [[Gecko:2DGraphicsThoughts/ErrorHandling]] | |||
=== API === | === API === | ||
| Line 25: | Line 26: | ||
We don't care about API stability. | We don't care about API stability. | ||
=== Remoting === | |||
We need an API that can be remoted very efficiently, since we'll need it for sandboxed content processes that want to use D2D or whatever for drawing. | |||
We probably need to assume from the start that system gfx libs can't be used in a sandboxed process. (Correct this if it's wrong!) | |||
Options for remoting seem to be | |||
# Map API to something like the cairo-image-surface backend; i.e., don't remote anything except references to rendered shmem images. | |||
# Map API to protocol designed exactly for remoting the API | |||
# Map API to GL, re-use GL protocol we'll need for webgl | |||
# Map API to backend-specific protocols | |||
We'll likely want (1) for systems without a GPU, although we might regress on systems with very good SW libs (on which we could potentially use (2) or (4) to erase the regression). To use D2D, we need either (2) or (4). (3) is attractive for sharing more code. (4) is unattractive for forking more code. | |||
(cjones) Seems like the best solution is to support (1) (on some thread) and (2). | |||
= Performance = | = Performance = | ||
| Line 70: | Line 87: | ||
* Reimplement gfxContext on top of new gfx API (compile time switch probably needed, or possibly a branch) | * Reimplement gfxContext on top of new gfx API (compile time switch probably needed, or possibly a branch) | ||
* Incrementally convert all our graphics code to the new API | * Incrementally convert all our graphics code to the new API | ||
= Meeting Notes = | |||
* Post-FF4, update cairo and plug in cairo-gl to canvas to see how it goes | |||
* Don't make a big investment in improving cairo-gl | |||
* Follow above plan | |||
* Do easy things to make new-gfx reusable by other projects (simple STL, bool, namespaces) but not hard things (threads) | |||
* Try GL backend on ANGLE before we commit to D3D backend(s) | |||
* Options for improving software rendering | |||
** New-API over Skia | |||
** Improve cairo | |||