Support multiple windows

[jrmuizel]

We'll need at least Webrender support for this for Webrender in Gecko.

[glennw]

I haven't thought about this too deeply... but it seems like the best way to implement this would be to create a new webrender instance for each window.

This would guarantee that rendering performance of one window would be unaffected by any rendering occurring in other windows (apart from OS / GPU driver scheduling that is outside our control anyway).

This would complicate migrating tabs between windows a bit (any images / webfonts / webgl contexts etc would need to be added to the different webrender interface) but seems doable. We will probably need similar code for when a content process dies and gets restarted anyway...

This would keep the webrender code simple, since it continues to just manage one GL context per instance.

If this is the agreed method, there's no changes required to webrender for this, and this task would only affect servo.

Thoughts @jrmuizel @pcwalton @metajack @larsbergstrom @jdm ?

[paulrouget]

If there are 2 windows, how many main::Browser, Constellation, WR and Compositor instances will be needed?

[pcwalton]

Yeah, what Glenn said seems right. There should only be one constellation and possibly multiple compositors (as I believe events are generally per-window in most toolkits).

[nical]

Does this mean having several Renderers on separate threads, or only RenderBackends on separate threads?

In Gecko I think that we would like to do the latter (have all Renderer objects on our Compositor thread).

[glennw]

@nical Just to be clear, does that mean that Gecko plans to share a single compositor thread between different windows?

[nical]

@glennw Yes, gecko currently has one compositor thread that all windows share.

[glennw]

@nical OK, that should work fine with multiple WR instances, I think. So you'd create one WR instance per window. This would be like you said above - each window would get its own RenderBackend thread, but the Renderer objects would all exist on the same compositor thread (this is fine since WR doesn't create any threads for the renderer object - it leaves this up to the calling code).

So in theory this should just work, I think. The only thing you'd need to make sure of is that the compositor thread binds/unbinds the right GL context for each window before calling functions on the associated renderer object.

Does that sound good to you?

[nical]

Something like that, in addition to fiddling with the event-loop. Currently the each Renderer has an IpcReceiver which it uses as an event loop. Gecko's compositor has its own event loop which we can't realistically get rid of, so I am looking into separating the Renderer from its messaging logic. The alternative is to have a separate dedicated thread for the Renderers (so they don't leave on a gecko event-loop), but either way we need the Renderers to share a single loop instead of blocking the thread on their respective result_rx.

[glennw]

We discussed this on Vidyo - WR should in theory integrate with external event loops OK. The renderer call in update() to pull data from an ipc-channel is only called when the external event is woken up and notified that a frame is available. @nical is doing some tests with this to make sure the assumptions hold.

[Ms2ger]

I vaguely remember a discussion on IRC that mentioned that things like X don't like being accessed from multiple threads. Is that still the case?

[jrmuizel]

XInitThreads enables Xlib support for concurrent threads. However, there are still gotchas.