Confirmed users
753
edits
(Created page with "= Overview = The surfaces discussed here are graphics surfaces that may have to be passed around between a producer and one or multiple consumers living either in the same pr...") |
No edit summary |
||
| Line 127: | Line 127: | ||
Once the above items are done, we should be able to call MozSurface the class created from the merging of TextureClient and TextureHost, and declare it our universal surface abstraction to use in all producer/consumer/ipc contexts. | Once the above items are done, we should be able to call MozSurface the class created from the merging of TextureClient and TextureHost, and declare it our universal surface abstraction to use in all producer/consumer/ipc contexts. | ||
Here is a diagram that fits together the present TextureClient/TextureHost classes, the near-future PTexture protocol pairing them, and how they would fit in the future MozSurface abstraction: | |||
*** Figure 3: The plan for MozSurface *** | |||
MozSurface | |||
+-------------------------------------------+ | |||
| | | |||
| +-------------+ +-----------+ | | |||
| |TextureClient| <---------> |TextureHost| | | |||
| +-------------+ PTexture +-----------+ | | |||
| | | |||
+-------------------------------------------+ | |||
| Line 155: | Line 170: | ||
*** Figure | *** Figure 4. JeffG and Dan's magic swap chain that allows *** | ||
*** consumers on multiple processes *** | *** consumers on multiple processes *** | ||