Hi Assert,
Awesome news!! As you said earlier we need this already yesterday. And while it may not be merged into the trunk of CEF at this time, it is really great to see someone who made an effort to provide accelerated OSR. I have thought about it myself more than a few times, but only the thought to set up the build environments kept me from getting into it.
However, since I wanted to try your work and provide some feedback I finally got everything set up and build Chromium and CEF with your patch - not as painful as I thought it would be -:)
Your patch seems to work very well and I have also verified that D3D path works. Rendering some 3D website using standard OSR loads CPU by 25% (this is 100% load of single core), rendering using accelerated OSR loads CPU only by 8% (includes CPU load by application). And this is great improvement! However, we having issues with this build. Our applications uses rendering to window as well as offscreen rendering. And it is important to have stable working components (this is not related to OSR patch). So, for example, we find out that cef_binary_3.1650.1562_windows32 build (without patch) renders black to window on some switchable graphics computers. It seems everything works (so CefBrowser changes cursor, reacts to clicks, JS calls sent to application, but just black window on screen). cef_binary_3.1846.1640_windows32 build compiled with your patch renders black even on some desktops. Disabling accelerated_compositing solves this issue. But then also no sense to use this CEF build then. So we currently can only stick to cef_binary_3.1547.1412_windows32 build which do not have these issues.
As you mentioned , then it may be a good idea to wait for next CEF sync point to continue . But just in case you actually make a patch that will work with latest trunk of CEF/Chromium then please do share.-:)
Comments Regarding API.
--------------------------------------
I think complete API will need also following:
1. Provide accelerated handle type. This can be OpenGL HDC, or D3D shared surface handle. So implementing application will know what kind of handle it gets without having prior knowledge of CEF parameters used.
2. Provide a way to switch back to non-accelerated OSR mode. Here 2 options: a) Application can create new browser, or b) Browser can do this switch.
Surfaces sharing may fail in some cases (for example, when you trying to open handle on another adapter, i.e. application and CEF works on different adapters).
Also, when D3D application receives OpenGL handle (or other way around), it can implement OpenGL->D3D sharing, or just switch back to non-accelerated mode. OpenGL->D3D is not available on all systems.
So switch back method required in any case.
There are also some general issues with surface sharing and switchable graphics in D3D. So it may be better to disable any accelerated OSR for now when switchable graphics system detected AND HANDLE PASSED FROM ANOTHER PROCESS (else this will require more effort to provide required API to handle all cases). In some cases OpenSharedResource call succeeded but CopyResource do not copy. This is NVidia and AMD issues because either CopyResource must work or OpenSharedResource returns failure.