- Performance tests
- how expensive is readback?
- need perf tests; ad-hoc popular popular sites for now, think about evolving into perf suite
- measure fps. somehow
- check android, d3d9, mac, GLX
- current, hacky-ish D3D10 cross-process layers implementation just renders all content to a single "back-buffer texture". In that world, the WebGL impl on d3d10 is the best we can do on top of ANGLE in the non-sandboxed world.
- if we update the D3D10 cross-process layers model to match the GL/Basic/D3D9 model, then it might be worthwhile to investigate sharing D3D9Ex textures across processes.
- if readback incurs high overhead, GL remoting is important
- otherwise, not very high priority
- Implement something like "GLContextProviderRemote"
- can use IPDL impl or chromium GL lib under that veneer
- IPDL impl would be very easy to ramp up; perf-tuning work is unknown
- importing chromium lib is unknown work; existing tuning is unknown
- need to figure out unknowns before deciding
- Security concerns (of either approach)
- GL command stream is untrusted by GPU process (assume content process has been pwned at all times); validate in chrome
- shaders are untrusted; validate in chrome, in addition to in content
- use a ring buffer to copy large chunks of data content->chrome asynchronously (if use IPDL, take chromium code as is? copy it?)
- glGetError() must be synchronous
- chrome must maintain its own local ring-buffer metadata; must validate content commands that mutate that metadata
- GL commands that reference data in the ring buffer (index buffers?) must copy the data out then validate it
joedrew signed up for this work.