Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd an example app using the DirectComposition API #2458
Conversation
https://msdn.microsoft.com/en-us/library/windows/desktop/hh449180(v=vs.85).aspx So far, the `InitializeDirectCompositionDevice` method.
|
|
||
| impl<T> ops::DerefMut for ComPtr<T> where T: Interface { | ||
| fn deref_mut(&mut self) -> &mut T { | ||
| unsafe { &mut *self.0 } |
This comment has been minimized.
This comment has been minimized.
emilio
Feb 22, 2018
Member
This is not sound, right? ComPtr is shared, so I can effectively do:
let mut a: ComPtr<T> = something_that_returns_a_comptr();
let mut b = a.clone();
let mut a: &mut T = &mut *a;
let mut b: &mut T = &mut *b;And get mutable aliasing.
This comment has been minimized.
This comment has been minimized.
SimonSapin
Feb 22, 2018
Author
Member
Oh right. I added this hoping to use deref coercions to get *mut IUnknown, ended up doing something else (see the as_ptr function), and forgot to remove it. retep998 had already pointed out that even mem::replace would be enough to make Bad Things happen if DerefMut exists.
|
The relevant code for hooking up ANGLE to DirectComposite exists in Chrome and Gecko in the following places: |
|
Bug 1191971 has wip patches to add DirectComposition support to RenderCompositorANGLE.cpp of gecko. |
|
ANGLE's support for DirectComposition seemed to be added originally for chromium's video overlay support. But current chromiun seemed not use it now. Instead, DirectCompositionSurfaceWin and DirectCompositionChildSurfaceWin are used. One tricky thing about video overlay is that we need to swith between video overlay rendering and normal WebRender video rendering depends on scene situation. In chromium, overlay usage decision is done around DirectRenderer, OverlayProcessor and CompositorOverlayCandidateValidatorWin. Actual DirectComposition layer is managed by DCLayerTree |
|
@jrmuizel In what form would you want to merge this? I intended this code as a stand-alone, it’s only in a branch of this repo because I didn’t bother creating a separate repo. If this is to become a library, what should be in scope for it? (For example, creating a D3D device? Creating a window?) At first I tried having a single renderer with multiple documents, but as far as I can tell both documents ended up rendered in both visuals. I think that what would be needed is some API to tell WR to only render one document. |
|
Also if we want this to be more than a demo we probably need to get full ANGLE packaged in a new crate, or expand https://github.com/servo/angle. |
I did this at https://github.com/servo/mozangle, by reading importing This demo app should now build with just |
|
|
SimonSapin
changed the title
|
This hits rust-lang/cargo#4866 (comment) when Perhaps I should make that Cargo feature be a no-op rather than a compile error, on platforms where it’s not supported? |
|
I’ve also made AppVeyor (try to) build this app, but: |
|
Oh, |
|
We should switch appveyor to to the msvc toolchain instead of gnu one. We don't use the gnu one in production |
|
r? @glennw |
|
@bors-servo r+ |
|
|
Add an example app using the DirectComposition API ~This PR is not intended to be merged, only to have a place to discuss while showing some code.~ <img src=https://user-images.githubusercontent.com/291359/36546140-e7a15da0-17ea-11e8-92fa-af320b32f4f2.PNG width=300> This is a standalone demo app that uses the `winit` crate to create a window, then uses COM APIs through the `winapi` crate to set up DirectComposition in this window with two "visuals", each a rectangle of a given size with its own Direct3D swap chain, render target, and context. One of the two visuals scrolls on `MouseWheel` events, without either of them being re-rendered. For now `ClearRenderTargetView` is used to fill each rectangle with a solid RGBA color. This is intended to be replaced with rendering arbitrary Direct3D content. ~A next step is probably integrating ANGLE so that separate OpenGL contexts can be created to render into respective visuals. I’m not sure where to start for this, though. ANGLE’s own documentation seems to be more about building than APIs.~ Looking up `directcomposition angle` specifically does yield some interesting things. It looks like ANGLE itself has some explicit support for DirectComposition: * https://bugs.chromium.org/p/chromium/issues/detail?id=524838 * https://bugs.chromium.org/p/angleproject/issues/detail?id=1178 * https://github.com/google/angle/blob/master/extensions/EGL_ANGLE_direct_composition.txt CC @jrmuizel @pcwalton @glennw ---- **Update:** the demo now renders with WebRender and ANGLE:  <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/2458) <!-- Reviewable:end -->
|
|
SimonSapin commentedFeb 22, 2018
•
edited
This PR is not intended to be merged, only to have a place to discuss while showing some code.This is a standalone demo app that uses the
winitcrate to create a window, then uses COM APIs through thewinapicrate to set up DirectComposition in this window with two "visuals", each a rectangle of a given size with its own Direct3D swap chain, render target, and context. One of the two visuals scrolls onMouseWheelevents, without either of them being re-rendered.For now
ClearRenderTargetViewis used to fill each rectangle with a solid RGBA color. This is intended to be replaced with rendering arbitrary Direct3D content.A next step is probably integrating ANGLE so that separate OpenGL contexts can be created to render into respective visuals. I’m not sure where to start for this, though. ANGLE’s own documentation seems to be more about building than APIs.Looking up
directcomposition anglespecifically does yield some interesting things. It looks like ANGLE itself has some explicit support for DirectComposition:CC @jrmuizel @pcwalton @glennw
Update: the demo now renders with WebRender and ANGLE:
This change is