Confirmed users
699
edits
Gecko:2DGraphicsThoughts: Difference between revisions
Jump to navigation
Jump to search
→Remoting
| Line 29: | Line 29: | ||
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 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 = | ||