Gecko:CrossProcessWebGL

• 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

• D3D10
  • 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.

• Priority
  • 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.