search

roadlabs / chromiumembedded

Automatically exported from code.google.com/p/chromiumembedded
0 stars 1 forks source link

CEF3: Support rendering to a hardware GL/D3D texture/surface provided by the client #1006

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
CEF3 off-screen rendering does not currently support hardware acceleration. 
This means that some features like 3D CSS which require hardware acceleration 
do not currently work when using off-screen rendering.

See issue #518 for related comments.

Original issue reported on code.google.com by magreenb...@gmail.com on 27 Jun 2013 at 5:50

GoogleCodeExporter commented 9 years ago 
Issue 1048 has been merged into this issue.

Original comment by magreenb...@gmail.com on 8 Aug 2013 at 4:05

GoogleCodeExporter commented 9 years ago 
Hi , I just wanted to follow up on this issues. I remember we had some good 
discussions  back in Issue 518 about a fairly simple approach to support GPU 
acceleration for off screen rendering on Windows by using shared surfaces.

Any idea on timeline here ?

Original comment by h...@splitmedialabs.com on 14 Feb 2014 at 5:30

GoogleCodeExporter commented 9 years ago 
Hello,

here it is a very interesting article about the Desktop Window Manager in 
Windows Vista, 7 and 8.

http://en.wikipedia.org/wiki/Desktop_Window_Manager

It seems in Windows Vista and beyond, all windows are actually textures that 
are rendered to an offscreen buffer and then put in a 3d surface (actually a 
D3D surface) representing that window.

Taking that into account I guess there must be an easy way to get the whole 
content (harware accelerated) from CEF and use it as a texture so that we can 
embed it in our own apps (see awesomium.com)

Probably this will only work in Windows Vista and beyond and not in Windows XP. 
I think CEF should support some of the features modern windows have to offer 
even if that breaks backwards compability with Win XP. I know many people love 
XP but we can't forget it is a 13 years old OS and many advancements have 
occurred since its release.

Original comment by efre...@gmail.com on 19 Feb 2014 at 7:11

GoogleCodeExporter commented 9 years ago 
I am working on patch for HW offscreen render support, description will be 
avail at CEF forum as soon as premoderated. Everyone who intrested in can join.

Original comment by MGusare...@gmail.com on 7 Apr 2014 at 8:25

Attachments:

GoogleCodeExporter commented 9 years ago 
@comment#4: The forum post is 
http://magpcss.org/ceforum/viewtopic.php?f=8&t=11635.

Original comment by magreenb...@gmail.com on 7 Apr 2014 at 2:49

GoogleCodeExporter commented 9 years ago 
Amazing re: the HW accelerated off screen rendering!  It really helps my use 
case with integrating CEF into QtQuick/QML scene graph without compromising.

Original comment by jarred.n...@gmail.com on 8 Apr 2014 at 7:38

GoogleCodeExporter commented 9 years ago 
There are currently two use cases for hardware acceleration:

1. Support for accelerated features like 3D CSS and WebGL which require GPU 
acceleration for rendering and compositing.

2. Support for delivering the final composited result to a GL/D3D 
texture/surface provided by the client in order to minimize copies and CPU load.

#1 will be addressed by issue #1257 which re-implements off-screen rendering 
support in trunk using the delegated renderer. #2 will be left to this issue.

Original comment by magreenb...@gmail.com on 28 Jun 2014 at 12:10

GoogleCodeExporter commented 9 years ago

Original comment by magreenb...@gmail.com on 28 Jun 2014 at 12:12

GoogleCodeExporter commented 9 years ago

Original comment by magreenb...@gmail.com on 23 Oct 2014 at 5:31

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
It's likely best to implement this at the Ozone layer. See 
http://crbug.com/431397 for details.

Original comment by magreenb...@gmail.com on 7 Nov 2014 at 10:00

GoogleCodeExporter commented 9 years ago 
Hello, any plans or aproximate date in which this feature will be added? thanks.

Original comment by efre...@gmail.com on 1 Mar 2015 at 1:39

GoogleCodeExporter commented 9 years ago 
My (possibly incorrect or outdated?) understanding is that Chromium renders to 
GPU-side 256x256 pixel tiles, rather than a single buffer that's the full size 
of the visible browser window. When something on the page changes, only tiles 
that are changed get redrawn. At display time, something called the 
"ubercompositor" takes the current list of tiles and merges it with 
browser-side UI things. The only time the entire web page is drawn into a 
single buffer is when the tiles are combined with that UI for the final render. 
I'm basing this off these two documents; if I'm wrong I welcome the correction:

https://docs.google.com/document/d/1tkwOlSlXiR320dFufuA_M-RF9L5LxFWmZFg5oW35rZk

https://docs.google.com/document/d/1ziMZtS5Hf8azogi2VjSE6XPaMwivZSyXAIIp0GgInNA

But if my understanding is correct, then implementing this as described would 
mean chromium or CEF would be rendering all its tiles to a buffer we provided, 
and then we'd render that buffer into our own view. But if the goal here is to 
reduce latency and copies, maybe the best way to achieve this isn't for CEF to 
render to a texture/surface that we provide. Instead, just expose the current 
tile set to us. We can send those tiles into our own 3D renderer as part of our 
own independently-running update/draw/present loop.

This would be especially appreciated by game developers, because we're 
frequently GPU-limited, and anything that reduces the number of GPU-side copies 
would help.

Original comment by ame...@gmail.com on 2 Mar 2015 at 10:55

GoogleCodeExporter commented 9 years ago 
CEF is transitioning from Google Code to Bitbucket project hosting. If you 
would like to continue receiving notifications on this issue please add 
yourself as a Watcher at the new location: 
https://bitbucket.org/chromiumembedded/cef/issue/1006

Original comment by magreenb...@gmail.com on 14 Mar 2015 at 3:26