CEF3: Add off-screen rendering support

[magreenblatt]

Original report by me.

---

Original issue 518 created by magreenblatt on 2012-02-13T19:15:26.000Z:

Add off-screen rendering support. See http://magpcss.org/ceforum/viewtopic.php?f=10&t=645 for CEF3 information.

[magreenblatt]

Original comment by Anonymous.

---

Comment 2. originally posted by normanhempel@fotona.de on 2012-04-28T14:07:04.000Z:

I wonder, is the off-screen rendering transparent color problem handled in CEF3? issue #584

[magreenblatt]

Original comment by Anonymous.

---

Comment 3. originally posted by 3eR0.1ive on 2012-05-07T23:54:35.000Z:

very important and useful feature!

[magreenblatt]

Comment 4. originally posted by magreenblatt on 2012-06-08T14:26:30.000Z:

This thread provides information on how to make transparency work with accelerated compositing: http://groups.google.com/a/chromium.org/group/chromium-dev/browse\_thread/thread/c3434035982c6a42

[magreenblatt]

Original comment by Anonymous.

---

Comment 5. originally posted by Feabauer on 2012-07-21T06:00:32.000Z:

I'm waiting this feature, performance of cef1 is not so ideal

[magreenblatt]

Original comment by Anonymous.

---

Comment 6. originally posted by chainara@essilor.fr on 2012-08-07T08:59:45.000Z:

Very useful functionnality

[magreenblatt]

Original comment by Anonymous.

---

Comment 7. originally posted by arroy.one on 2012-08-24T16:54:40.000Z:

killer feature! What platforms will be supported?

[magreenblatt]

Comment 8. originally posted by magreenblatt on 2012-09-05T14:45:40.000Z:

CEF1's off-screen rendering API currently supports the following methods:

Methods that the client implements:

• GetScreenRect: Called to return the screen bounds. Used for constraining popup widget size and placement.
• GetViewRect: Called to return the position of the view relative to the screen bounds.
• OnPopupShow: Called when the browser wants to show or hide the popup widget.
• OnPopupSize: Called when the browser wants to move or resize the popup widget.
• OnPaint: Called to paint the view or popup widget. Provides dirty rectangles and a pixel buffer.
• OnCursorChange: Called when the cursor changes.

Methods that the browser provides:

• GetSize: Returns the size of the view or popup widget.
• SetSize: Sets the size of the view or popup widget.
• Invalidate: Force repaint and call OnPaint() for the specified region.
• SendKeyEvent: Notify the view of keyboard events.
• SendMouseClickEvent: Notify the view of mouse click events.
• SendMouseMoveEvent: Notify the view of mouse move events.
• SendMouseWheelEvent: Notify the view of mouse wheel events.
• SendFocusEvent: Set or remove focus from the view.

To implement off-screen rendering with CEF3 and the Content API we will need to provide our own WebContentsView and RenderWidgetHostView implementations via ContentBrowserClient::OverrideCreateWebContentsView(). These interfaces currently have methods that return platform-defined handle types (gfx::NativeView and gfx::NativeWindow). We don't want to change the definitions of these types in native_widget_types.h because CEF supports both off-screen rendering and "default" native windows in the same binary. Consequently, we can (a) always return NULL from these methods and provide my own implementation methods to return identifiers, or (b) cast identifiers to/from the platform type. It seems like (a) would be a safer option. There should be no code outside of the WebContentsView and RenderWidgetHostView implementation that requires the return of a valid platform handle, but we will need to audit the code to make sure.

We will also need to determine if it's possible to support accelerated content in off-screen rendering. Chromium currently uses a separate process to manage the GPU pipeline. Implementation details are available at http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome.

[magreenblatt]

Original comment by Anonymous.

---

Comment 9. originally posted by hele@splitmedialabs.com on 2012-09-05T15:59:36.000Z:

Its fantastic to see that some work is being done to support this feature. Its truly an important feature. It will also be great to find out if it will be possible to support accelerated content in off-screen. - that would be awesome.

@ Marshall : Thanks or your great work !!

[magreenblatt]

Original comment by Anonymous.

---

Comment 10. originally posted by askthegimp on 2012-09-18T07:39:13.000Z:

One more vote for this feature! Great stuff.

[magreenblatt]

Original comment by Anonymous.

---

Comment 11. originally posted by jochen.heckl on 2012-09-22T14:56:26.000Z:

+1 for bringing this feature in soon

[magreenblatt]

Original comment by Anonymous.

---

Comment 12. originally posted by cosmo.shih on 2012-09-25T09:51:32.000Z:

In most case, off-screen rending is required, because users want to get raw content data and render contents by some specific technology, not just render into a native window.
Unfortunate, GPU accelrating is highly platform-dependent(not just OS, but software enviroment), and there is leaking a generic inter-process GPU resource sharing mechanism, so off-screen rending can't utilizing GPU effectively.
Because Chromium GPU process just paints content into screen directly which rely on Direct3D internal Device <-> SwapChain <-> HWND mapping. There is no way to get the content from Vedio-Card effectively from another process as I know.
Just rending with GPU, then transfer contents from VRAM to RAM for inter-process communication doesn't make sense, cause VRAM to RAM transfer horribly slow.

[magreenblatt]

Original comment by Anonymous.

---

Comment 13. originally posted by efrencd on 2012-09-25T15:42:35.000Z:

First of all excuse my ignorance in this topic, I'm not a c++ programmer.

I got two questions:

1. Even moving things from VRAM to RAM is very costly... Isn't it even slower to let the software renderer try to process things such as WebGL? What is the expected framerete we could get at for example full HD resolution coping form VRAM to RAM in a fast machine?

2. Things such as Nvia GPU Direct feature on some of their cards wouldn't be helpfull on that case?

http://developer.nvidia.com/cuda/nvidia-gpudirect

[magreenblatt]

Comment 14. originally posted by magreenblatt on 2012-09-25T15:52:42.000Z:

@ comment comment 12.-13: We can potentially composite to a system memory buffer (bitmap) and share it with the browser process instead of having the GPU process write directly to the display. This will result in increased CPU usage but we should be able to maintain a reasonable frame rate (>=24fps). Using software rendering for WebGL isn't a viable option.

[magreenblatt]

Original comment by Anonymous.

---

Comment 15. originally posted by cosmo.shih on 2012-09-26T01:43:41.000Z:

@ comment comment 13.:

1. There is no generic estimation. As I said, It's highly platform-dependent. Maybe high-end system can do VRAM->RAM transfer at a reasonable frame rate.
2. We need a generic way deal with GPU resource sharing for browser. Not only Nvidia Cards.

@ comment comment 14.:
Software rendering seem like the only chose for off-screen render. so GPU-intense function isn't practical in near future.

[magreenblatt]

Original comment by Anonymous.

---

Comment 16. originally posted by cosmo.shih on 2012-09-26T03:21:56.000Z:

@ comment comment 8.:
Implementing a RenderWidgetHostView seems like require a lot of work to do. Any thing has been done?

[magreenblatt]

Original comment by Anonymous.

---

Comment 17. originally posted by iohanson on 2012-09-26T07:33:47.000Z:

@ comment comment 16.
I started working on this feature. I already have a working prototype on windows and it would probably take a couple more weeks to get things well done.

[magreenblatt]

Original comment by Anonymous.

---

Comment 18. originally posted by zak.nelson on 2012-09-26T07:49:14.000Z:

Would love to see a patch if you can share. I was about to dive into implementation on the mac side, but may hold off if you're almost done...

[magreenblatt]

Original comment by Anonymous.

---

Comment 19. originally posted by dreijerbit on 2012-09-26T13:04:32.000Z:

@ comment comment 12.:

Windows Vista and higher all have support for shared Direct3D resources (http://msdn.microsoft.com/en-us/library/windows/desktop/ee913554%28v=vs.85%29.aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/bb219800%28v=vs.85%29.aspx\#Sharing\_Resources), so if there's a way to get the shared handle to the application that uses CEF, then it's definitely possible to use hardware acceleration for offscreen rendering.

[magreenblatt]

Original comment by Anonymous.

---

Comment 20. originally posted by hele@splitmedialabs.com on 2012-09-26T13:53:49.000Z:

It's possible to share surface on GPU if a d3d9ex device is created by chrome instead of d3d9. There are minimal differences between a ex device and regular d3d9 device in terms of API except for a small name change to a few functions as I remember. So it is possible that absolute minimal code change in Chromium could resolve the issue and pave way for super effective surface sharing.

So if another process is using d3d9ex, d3d10.1 or d3d11 it can copy surface directly in video memory and avoid round-trip to system memory. This will save considerable CPU and have much less performance impact in cases where result is needed back in video memory (most cases when off-screen rendering uses I presume)

However , we need to support any operating system even XP, so what could be done is to simply try to create d3d9ex device and then create regular d3d device if creating d3d9ex fails (so hence reverting to video - >system memory round trip) . I think this should be a pretty bullet proof way to maintain full support for all operating systems at least on windows.

Disclaimer: I stopped actually programming myself a few years back (except on very cold winter nights) , but this is at least what I have learned from our applications usage of D3D technology.

[magreenblatt]

Original comment by Anonymous.

---

Comment 21. originally posted by cosmo.shih on 2012-09-27T01:07:13.000Z:

@ comment comment 19.-20:
Thanks for you information. I'll dig into it.

[magreenblatt]

Original comment by Anonymous.

---

Comment 22. originally posted by cosmo.shih on 2012-09-27T02:28:26.000Z:

Is there a similar way to do GPU resource sharing on other platform via OpenGL.

[magreenblatt]

Original comment by Anonymous.

---

Comment 23. originally posted by cosmo.shih on 2012-09-27T02:53:06.000Z:

Chromium do not talk to Direct3D directly. Is it similar mechanism to do resource sharing in OpenGL? Is it possible introduce this feature to ANGEL? Do we need a complete new off-screen browser?

[magreenblatt]

Original comment by Anonymous.

---

Comment 24. originally posted by cosmo.shih on 2012-09-27T03:11:31.000Z:

It is seem like impossible to build a prototype above Content API? the GPU accelerating architecture is hidden under Content API without public interface. Do I missing some thing?

[magreenblatt]

Original comment by Anonymous.

---

Comment 25. originally posted by efrencd on 2012-10-10T16:28:17.000Z:

Hi guys, I have sent an email to Vangelis Kokkevis, owner of the ANGLE project at google about the possibility to get the rendered result in the hardware acelerated path.

This is his answer, may we can get some ideas from it:

Hi Efren,
ANGLE is probably not the right group for this discussion. What you're asking should in theory be possible to do with Chrome already. Our windows port on Win Vista or later doesn't actually render web content straight to a window. The GPU process output goes into a surface (texture) which is then passed over to the browser process which does the final present via a separate D3D device. All that happens without a readback. The relevant file to start unraveling this mechanism is:

http://code.google.com/searchframe\#OAMlx\_jo-ck/src/content/common/gpu/image\_transport\_surface\_win.cc&exact\_package=chromium&q=image\_transport\_surface\_win&type=cs&l=1

[magreenblatt]

Original comment by Anonymous.

---

Comment 26. originally posted by dreijerbit on 2012-10-10T16:58:03.000Z:

So, if I'm reading this right it means the browser is already presenting via a D3D device, which again means it's trivial for us to use it for offscreen rendering.

comment 17.: How far along are you with the prototype on Windows? I'd be strongly in favor of at least getting rudimentary support (i.e. non-hardware-accelerated) in to CEF3 as soon as possible. It won't be any faster than CEF1/2, but it also won't be slower.

Offscreen rendering is such a core feature than I'm kind of unclear why it hasn't been prioritized more in CEF3.

[magreenblatt]

Original comment by Anonymous.

---

Comment 27. originally posted by iohanson on 2012-10-11T19:34:49.000Z:

I'm working on unit tests. It should be ready in a day or two.

[magreenblatt]

Original comment by Anonymous.

---

Comment 28. originally posted by dreijerbit on 2012-10-11T19:43:35.000Z:

Awesome, thanks for doing this!

[magreenblatt]

Original comment by Anonymous.

---

Comment 29. originally posted by a.dionisi@shinyweb.it on 2012-10-13T23:05:11.000Z:

any news?

[magreenblatt]

Original comment by Anonymous.

---

Comment 30. originally posted by iohanson on 2012-10-15T21:02:35.000Z:

I've attached the patch containing a windows only off-screen rendering implementation, cefclient off-screen rendering mode implementation (--off-screen-rendering-mode-enabled) and unit tests.

Popup widgets (like drop down boxes) are not working with this off-screen rendering implementation. The reason is that Chromium Content Module doesn't call CEF to create off-screen views for these widgets. I logged a bug to chromium with this issue: http://code.google.com/p/chromium/issues/detail?id=155761.

GetScreenRect is missing from CEF3's CefRenderHandler, because Chromium Content Module doesn't request it from the client.

There is some more work to be done regarding performance (eg. a backing store optimized for off-screen rendering).

[magreenblatt]

Comment 107. originally posted by magreenblatt on 2013-04-12T21:26:25.000Z:

@ commentcomment 10.3-104: Building with your patches using the 10.6 SDK on OS-X I'm getting the following errors:

cefclient_osr_widget_mac.mm:65:17: Use of undeclared identifier 'NSWindowDidChangeBackingPropertiesNotification'; did you mean 'NSWindowDidChangeScreenProfileNotification'?
cefclient_osr_widget_mac.mm:72:22: Use of undeclared identifier 'NSWindowDidChangeBackingPropertiesNotification'; did you mean 'NSWindowDidChangeScreenProfileNotification'?
cefclient_osr_widget_mac.mm:277:5: Instance method '-setWantsBestResolutionOpenGLSurface:' not found (return type defaults to 'id')
cefclient_osr_widget_mac.mm:728:45: Use of undeclared identifier 'NSBackingPropertyOldScaleFactorKey'
cefclient_osr_widget_mac.mm:762:25: Instance method '-backingScaleFactor' not found (return type defaults to 'id')
cefclient_osr_widget_mac.mm:762:23: Assigning to 'float' from incompatible type 'id'
cefclient_osr_widget_mac.mm:818:20: Instance method '-convertSizeToBacking:' not found (return type defaults to 'id')
cefclient_osr_widget_mac.mm:818:18: No viable overloaded '='
cefclient_osr_widget_mac.mm:828:26: Instance method '-convertRectToBacking:' not found (return type defaults to 'id')
cefclient_osr_widget_mac.mm:828:12: No viable conversion from 'id' to 'NSRect' (aka '_NSRect')
cefclient_osr_widget_mac.mm:841:26: Instance method '-convertRectFromBacking:' not found (return type defaults to 'id')
cefclient_osr_widget_mac.mm:841:12: No viable conversion from 'id' to 'NSRect' (aka '_NSRect')

It seems that NSWindowDidChangeBackingPropertiesNotification and related functionality was added in 10.7.3. 10.6 is still a supported platform so please change this code to compile/run with the 10.6 SDK.

Also, your WebView changes did not compile on OS-X due to the use of the static WebView::setUseExternalPopupMenus() function in RenderThreadImpl::Init().

Attached is an updated patch at trunk revision 1220 that combines your osr_mac4.1 and osr_mac_popups4 patches with the following additional changes:

1. Refactor the WebView patch to compile, minimize the required changes, properly initialize variables, etc.
2. Various documentation and style fixes.

Please use this new patch as the basis for fixing the above cefclient_osr_widget_mac.mm errors or just attach a new copy of cefclient_osr_widget_mac.mm with the necessary changes. Thanks :-).

[magreenblatt]

• set attachment to "osr_mac5.patch"

[magreenblatt]

Original comment by Anonymous.

---

Comment 108. originally posted by horia.olaru on 2013-04-15T18:58:26.000Z:

Thanks for taking the time to review the patch, and fixing stuff here and there :)

All of the above API errors are directly related to supporting HiDPI. They indeed became available only in the 10.7 OS and SDK, but that is because HiDPI became available to developers at that time.

The Mac OSX SDKs have a mechanism in place to build a binary with a minimum 'deployment target' OS, for backwards compatibility with previous OS versions. This way, with a 10.7 SDK one can set the deployment target to 10.6, and the resulting binary will be able to run on 10.6 and higher. The newer APIs are used only if they are available at runtime, but the developer is responsible for checking if they are (respondsToSelector).

cefclient is the only project that actually accesses the platform specific view / screen APIs, to determine DPI settings. Hence the only one that requires a specific OS X SDK is cefclient. The rest of the code is platform agnostic.

The alternatives I see are:

1. Use ifdefs to only exclude the HiDPI code from 10.6 SDK builds of cefclient. However, this means that the resulting binary would not have HiDPI support even when run on 10.7 or 10.8. To enable that support, another build with a 10.7 SDK or newer would be needed.
2. Migrate to using Mac OSX SDK 10.7 to build cefclient, but set the deployment target to 10.6.

The 2nd option is what I had in mind initially, as I had set in place the runtime checks to make cefclient work on 10.6. I've added an extra runtime check on the notifications code, because for some reason it seemed to crash on 10.6.

I am attaching cefclient_osr_widget_mac.mm with all the offending code between 'ifdefs', but if you remove those, the code should work fine on 10.6 as described in 2.

[magreenblatt]

Original comment by Anonymous.

---

Comment 109. originally posted by horia.olaru on 2013-04-15T19:00:21.000Z:

@ 108 - adding the attachment, which for some reason did not get attached.

[magreenblatt]

Original changes by Anonymous.

---

• set attachment to "cefclient_osr_widget_mac.mm"

[magreenblatt]

Comment 110. originally posted by magreenblatt on 2013-04-16T19:26:40.000Z:

Mac support has been added in trunk revision 1226 and 1453 branch revision 1227. Thanks to all the people who helped out on this!

Build with the 10.7 SDK (set GYP_DEFINES='mac_sdk=10.7') to include Retina support in the cefclient OSR example as described in comment comment 10.8.

[magreenblatt]

Original comment by Anonymous.

---

Comment 111. originally posted by dpokrovskii@secondstory.com on 2013-04-23T21:10:05.000Z:

I am rendering (Windows 7) off-screen using transparent painting. All of my transparent png's render just fine but fonts don't (see attached image). I'm not using any custom fonts, just the standard Serif Font. Is this a limitation of Cef?

In the Cef example, Cef3 is rendering off screen and storing the result as a texture on a quad. A white quad is behind the chrome texture.

[magreenblatt]

Original changes by Anonymous.

---

• set attachment to "cef_offscreen_font.png"

[magreenblatt]

Comment 112. originally posted by magreenblatt on 2013-04-23T21:15:01.000Z:

@ commentcomment 11.1: You can try toggling the use of SKIA vs GDI for text rendering to see if it makes an improvement. Change the value of 'enable_skia_text' in cef.gypi and then re-build CEF/Chromium.

[magreenblatt]

Original comment by Anonymous.

---

Comment 113. originally posted by berkeley.inc on 2013-05-16T15:33:57.000Z:

What would be a good start to implement wmodes of 'direct' or 'window' for flash in offscreen CEF (Windows)?
Since flash has its own HWND for these render-modes, my first idea was it to pretend the Visible flag for this HWND and Hook the BeginPaint function so that it returns my own DC. After that, you could send WM_PAINT Messages for the Update of the Flash's HWND.
Is there maybe a simpler way?

[magreenblatt]

Comment 114. originally posted by magreenblatt on 2013-05-16T15:38:52.000Z:

@ commentcomment 11.3: Using windowed plugins with off-screen rendering rather defeats the purpose. Either use windowed rendering or windowless plugins.

[magreenblatt]

Original comment by Anonymous.

---

Comment 115. originally posted by berkeley.inc on 2013-05-16T15:52:06.000Z:

Well, I have got a flash website, which uses Stage3D. Forcing this flash site to use opaque or transparent modes only results in a black screen.
My purpose was it to create the windowed plugin, but leave it hidden and let it render to an own Device Context.
I'm asking if there is maybe another method to use Stage3D with hardware acceleration in offscreen mode?

• or is it something you cannot change, as the flash plugin itself is responsible for it?

[magreenblatt]

Comment 116. originally posted by magreenblatt on 2013-05-16T15:54:55.000Z:

@ commentcomment 11.5: Windowed plugins are responsible for their own rendering. So the window for windowed plugins needs to be visible and parented/positioned correctly.

[magreenblatt]

Original comment by Anonymous.

---

Comment 118. originally posted by vincent.li@ubitusinc.com on 2013-06-20T09:28:59.000Z:

Hi everyone,
I'm trying to get accelerated rendering work under osr mode.

in browser_host_impl.cc, CefBrowserSettings::accelerated_compositing was original coded to become STATE_DISABLED when osr is enabled.
I modify this part to allow CefBrowserSettings::accelerated_compositing as it is.

When testing with https://www.webkit.org/blog-files/3d-transforms/poster-circle.html

I observed a gpu-process was spawned, but the rendering path seems to be software rendering instead. Actually the gpu-process looks like no action at all, consuming no cpu resource. So I think I must have done something wrong to make the hardware rendering path no work.

My understand is if the hardware rendering path is on its way, takes windows platform for example, a DirectX 3d shared resource handle will be available for browser process to use.

Please kindly let me know if it is possible to make chrome rendering the hardware path even if currently we cannot capture the rendering result under osr mode.

Thanks.

[magreenblatt]

Original comment by Anonymous.

---

Comment 119. originally posted by vincent.li@ubitusinc.com on 2013-06-21T02:10:17.000Z:

Hi everyone,
I traced the code between different process and finally found why hardware rendering path is not working. It is because in CefRenderWidgetHostViewOSR::GetCompositingSurface, a null handle was returned. By Comparing with its RenderWidgetHostViewWin::GetCompositingSurface counterpart. I think it is the place to begin with.

Thanks.

[magreenblatt]

Original comment by Anonymous.

---

Comment 120. originally posted by rosca@adobe.com on 2013-06-21T07:08:55.000Z:

Off-screen rendering is meant to be used for those who need an array of bytes containing the webview. If you want to enable hardware acceleration, the web content will go to an accelerated surface and you should copy from that surface back to your buffer. This is going to be very expensive.
Can you describe the use case, why do you need OSR & hardware acceleration, why a non OSR, hardware accelerated browser instance wouldn't be an option.

[magreenblatt]

Original comment by Anonymous.

---

Comment 121. originally posted by vincent.li@ubitusinc.com on 2013-06-21T08:02:17.000Z:

Yes, it is best not to read the data bytes back from GPU for the performance concern.
In my use case, I am not really trying to render the web contents to window, what really concerns is the data bytes, no matter where they are.

If they are placed on the GPU, I would make use of these data in the GPU way, anyway. As I said, there will be a shared resource in hardware-rendering path. I think it would be fine to make use of this resource.

[magreenblatt]

Original comment by Dmitry Azaraev (Bitbucket: Mystic Artifact).

---

Comment 122. originally posted by fddima on 2013-06-21T08:14:09.000Z:

@ commentcomment 12.0: without hardware acceleration no any css 3d transforms works. So if we will see from rendering correctness point - we must no have concern about performance penalties, 'cause fast code which work incorrectly - incorrect code. ;)
also it is not bad idea have capabilities to rendering in specific surface (directx) - in this case it is can be more easy to embedd it in directx-based applications.

[magreenblatt]

Original comment by Anonymous.

---

Comment 124. originally posted by rosca@adobe.com on 2013-06-21T08:46:14.000Z:

@ commentcomment 12.2
It would be really nice to have the capability to render into a specific surface, but this sounds to a feature besides OSR.
I wouldn't say that non-accelerated rendering works incorrectly, it's more like it has limited capabilities and it works as intended. If you'd like to have an off-screen buffer for each frame, you'd probably not be able to replay a smooth animations from them. If you want an off-screen buffer with a webview snapshot, there should be options to do this without off-screen rendering.

[magreenblatt]

Original comment by Dmitry Azaraev (Bitbucket: Mystic Artifact).

---

Comment 125. originally posted by fddima on 2013-06-21T12:14:10.000Z:

@ commentcomment 12.4: Sorry, may be my previous message may be not completely understandable. Incorrectness of OSR are not in technical details / implementation - it incorrect from default user expectation (i.e. users are waiting same behavior as windowed mode). There is not first GPU & OSR discussion, and most of them we always speak about lack of performance, but i just point, that also other point of view on same problem exists -> it is get worked available already implemented features without concern of performance. Of course more performant solution is better. :)

[magreenblatt]

Comment 126. originally posted by magreenblatt on 2013-06-21T19:24:08.000Z:

The attached patch against trunk revision 1280 adds off-screen rendering support on Linux. I've only tested it on Ubuntu 12.04 64-bit so far. The cefclient OSR example adds a new dependency on the libgtkglext1-dev package.

It would be great if someone with linux/GTK experience could review this patch. I plan to commit it some time next week (trunk and 1453 branch).

[magreenblatt]

• set attachment to "osr_linux_trunk_1280.patch"

[magreenblatt]

Original comment by Anonymous.

---

Comment 127. originally posted by predator_mf2000@yahoo.com on 2013-06-22T10:46:44.000Z:

Any ideas why CEF3 with offscreen rendering doesn't render flash (e.g. youtube videos)? My guess is it needs the same windowless-flash patch as in CEF1

[magreenblatt]

Comment 128. originally posted by magreenblatt on 2013-06-24T16:51:19.000Z:

Trunk revision 1285 and 1453 branch revision 1286 force flash and silverlight plugins to windowless mode when using off-screen rendering.

[magreenblatt]

Comment 129. originally posted by magreenblatt on 2013-06-27T17:37:05.000Z:

issue #594 has been merged into this issue.

[magreenblatt]

Comment 130. originally posted by magreenblatt on 2013-06-27T17:53:31.000Z:

Linux off-screen rendering support added in trunk revision 1294 and 1453 branch revision 1295.

This issue is now closed:
* File new bugs or feature requests as a separate issue (search first to make sure it doesn't already exist).
* Use the CEF Forum for questions related to off-screen rendering.
* Support for hardware acceleration will be discussed in issue comment 10.06.

[magreenblatt]

• set state to "resolved"