Hi, this plan looks like a great improvement over the current state of webgl in servo.
> * WebGL commands are currently run in the WR backend thread which could > be > bad for UI latency (see https://github.com/servo/webrender/issues/607) Yeah, thanks for getting rid of this! > The connection between a WebGL canvas and WR is implemented via the WR > ExternalImage APIs as Glennw recommended. Great! > The new architecture creates a single thread/process to manage all WebGL > commands from multiple canvas sources. This will reduce the footprint for > creating a new canvas (avoid creating specific thread + ipc-channel) and > reduces the render-path for each WebGL command by using a single "channel > step" Cool, the thread-per-canvas thing is insane. > we may be interested in > batching WebGLCommands, using shared memory, or other channel approaches > to improve performance. You probably already have, but I suggest having a look at what chrome's doing in this are (batching up commands to send to their GPU process instead of sending each command) > * Immediate WebGL calls to a GL context living in the Script thread (I > did > some benchmarks with this enabled (sometimes it's faster running the gl > call than sending it) . I'd like to focus on a thread bases render path > though in order to parallelize JS code better) In-script-thread webgl is also good for latency. Currently Chrome's VR implementation has an extra frame of latency compared to Firefox (which I believe is due to the gl remoting) and it is very noticeable in VR. > * WebGL double buffering: It may be a good idea to improve performance > and > synchronization (e.g. ping pong WebGL render textures each frame, so WR > uses a texture to composite the main context while the WebGL frame is > rendering the next frame to a different texture). This may add some > memory > overhead. We can implement some texture pooling (I think that Firefox > does > that) Yes, Firefox does that. > * How does the SpiderMonkey version used in Servo compare to V8? SpiderMonkey is doing particularly well on the games type of things compared to V8 (for various good and bad reasons). There's also the better support for asmjs. More generally, I'd rather avoid picking the competitor's tech instead of ours unless there is a very strong incentive because of the PR foot-gun that it generates. Cheers, Nical _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
