|
53ea9cc6
|
2016-05-17T10:12:52
|
|
Replace rx::Renderer with rx::ContextImpl.
Previously Context had no Impl class, but had a special relationship
with the instanced Renderer class. Having a ContextImpl backing every
Context will allow new designs to enable things like multithreading
(where each ContextImpl stores a Context-specific device) or non-
virtual Contexts on Android or other platforms where it is more
efficient.
A large refactoring patch that touches every back-end.
BUG=angleproject:1363
Change-Id: Icb73a7d37447f08a664eeb499a310ba05d71a57e
Reviewed-on: https://chromium-review.googlesource.com/342052
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
8415b5fd
|
2016-04-26T13:41:39
|
|
Pass ContextImpl to Framebuffer methods instead of ContextState.
BUG=angleproject:1363
Change-Id: I7e7524d95f2ca31c35918f9fe5c0cb681ed93616
Reviewed-on: https://chromium-review.googlesource.com/340746
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
437fa654
|
2016-05-03T15:13:24
|
|
Add a ContextImpl class.
This class can contain impl-specific functionality for a Context.
This will eventually replace the Renderer class, and we can then
start passing around a gl::Context instead of gl::ContextState.
In D3D11, the ContextImpl could hold a DeferredContext, which would
enable multi-thread rendering. In GL, we can implement non-virtual
(native) Contexts. In Vulkan it might store the logical device.
BUG=angleproject:1363
Change-Id: I39617e6d1a605d1a9574832e4d322400b09867ec
Reviewed-on: https://chromium-review.googlesource.com/340745
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|