CEF3: Add off-screen rendering support

[GoogleCodeExporter]

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

Original issue reported on code.google.com by magreenb...@gmail.com on 13 Feb 2012 at 7:15

• Blocking: #887

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Original comment by normanhe...@fotona.de on 28 Apr 2012 at 2:07

[GoogleCodeExporter]

very important and useful feature!

Original comment by 3eR0.1...@gmail.com on 7 May 2012 at 11:54

[GoogleCodeExporter]

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

Original comment by magreenb...@gmail.com on 8 Jun 2012 at 2:26

[GoogleCodeExporter]

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

Original comment by Feaba...@gmail.com on 21 Jul 2012 at 6:00

[GoogleCodeExporter]

Very useful functionnality

Original comment by chain...@essilor.fr on 7 Aug 2012 at 8:59

[GoogleCodeExporter]

killer feature! What platforms will be supported?

Original comment by arroy....@gmail.com on 24 Aug 2012 at 4:54

[GoogleCodeExporter]

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.

Original comment by magreenb...@gmail.com on 5 Sep 2012 at 2:45

[GoogleCodeExporter]

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 !!

Original comment by h...@splitmedialabs.com on 5 Sep 2012 at 3:59

[GoogleCodeExporter]

One more vote for this feature! Great stuff.

Original comment by asktheg...@gmail.com on 18 Sep 2012 at 7:39

[GoogleCodeExporter]

+1 for bringing this feature in soon

Original comment by jochen.h...@gmail.com on 22 Sep 2012 at 2:56

[GoogleCodeExporter]

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.

Original comment by cosmo.s...@gmail.com on 25 Sep 2012 at 9:51

[GoogleCodeExporter]

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

Original comment by efre...@gmail.com on 25 Sep 2012 at 3:42

[GoogleCodeExporter]

@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.

Original comment by magreenb...@gmail.com on 25 Sep 2012 at 3:52

[GoogleCodeExporter]

@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 #14:
Software rendering seem like the only chose for off-screen render. so 
GPU-intense function isn't practical in near future.

Original comment by cosmo.s...@gmail.com on 26 Sep 2012 at 1:43

[GoogleCodeExporter]

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

Original comment by cosmo.s...@gmail.com on 26 Sep 2012 at 3:21

[GoogleCodeExporter]

@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.

Original comment by iohan...@gmail.com on 26 Sep 2012 at 7:33

[GoogleCodeExporter]

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...

Original comment by zak.nel...@gmail.com on 26 Sep 2012 at 7:49

[GoogleCodeExporter]

@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.a
spx and 
http://msdn.microsoft.com/en-us/library/windows/desktop/bb219800%28v=vs.85%29.as
px#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.

Original comment by dreijer...@gmail.com on 26 Sep 2012 at 1:04

[GoogleCodeExporter]

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. 

Original comment by h...@splitmedialabs.com on 26 Sep 2012 at 1:53

[GoogleCodeExporter]

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

Original comment by cosmo.s...@gmail.com on 27 Sep 2012 at 1:07

[GoogleCodeExporter]

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

Original comment by cosmo.s...@gmail.com on 27 Sep 2012 at 2:28

[GoogleCodeExporter]

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?

Original comment by cosmo.s...@gmail.com on 27 Sep 2012 at 2:53

[GoogleCodeExporter]

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?

Original comment by cosmo.s...@gmail.com on 27 Sep 2012 at 3:11

[GoogleCodeExporter]

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_tran
sport_surface_win.cc&exact_package=chromium&q=image_transport_surface_win&type=c
s&l=1

Original comment by efre...@gmail.com on 10 Oct 2012 at 4:28

[GoogleCodeExporter]

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.

#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.

Original comment by dreijer...@gmail.com on 10 Oct 2012 at 4:58

[GoogleCodeExporter]

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

Original comment by iohan...@gmail.com on 11 Oct 2012 at 7:34

[GoogleCodeExporter]

Awesome, thanks for doing this!

Original comment by dreijer...@gmail.com on 11 Oct 2012 at 7:43

[GoogleCodeExporter]

any news?

Original comment by a.dionisi@shinyweb.org on 13 Oct 2012 at 11:05

[GoogleCodeExporter]

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).

Original comment by iohan...@gmail.com on 15 Oct 2012 at 9:02

Attachments:

• osr1.patch

[GoogleCodeExporter]

@comment 30: Nice job!

Question: Is this off-screen rendering method GPU acelerated based on what is 
posted on @comment 25??

Regards!

Original comment by efre...@gmail.com on 21 Oct 2012 at 2:46

[GoogleCodeExporter]

@comment#30: Thanks for the patch. I haven't had a chance to fully review it 
but here are some initial comments:

1. Do we need the OFF_SCREEN_RENDERING define? Does something break with 
windowed rendering when this feature is enabled?

2. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
30000&name=osr1.patch&token=9vi5qQZELd60Saw1_Fh__F5BrtI%3A1350941942419#1299

+ ///
+ // Notify browser that widget was resized. This method is only used
+ // when window rendering is disabled.
+ ///
+ /*--cef()--*/
+ virtual void WasResized() =0;

We should explain in the comments when this method should be called, and what 
happens after calling it. For example, will CefRenderHandler::GetViewRect be 
called to retrieve the new size?

3. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
30000&name=osr1.patch&token=9vi5qQZELd60Saw1_Fh__F5BrtI%3A1350941942419#1893

+ scoped_ptr<skia::PlatformCanvas> canvas(new skia::PlatformCanvas());
+ if (backing_store->CopyFromBackingStore(gfx::Rect(backing_store->size()),
+ canvas.get())) {

It seems inefficient to create a new PlatformCanvas each time 
CefRenderWidgetHostViewOSR::Paint is called. Ideally we should create a new 
PlatformCanvas when the view is resized and otherwise just update the invalid 
regions in Paint.

Original comment by magreenb...@gmail.com on 22 Oct 2012 at 9:59

[GoogleCodeExporter]

@comment#32: Thanks for the comments!
1. The OFF_SCREEN_RENDERING define is used to compile off-screen rendering 
specific code only for specific platforms (in this patch, it's only enabled on 
windows). The lines of code under the OFF_SCREEN_RENDERING flag aren't platform 
specific (so, I wouldn't put them under OS_WIN), but they don't yet compile on 
non-windows platforms.
2. I will change it within the next patch
3. This is included in my TODO list

Original comment by iohan...@gmail.com on 23 Oct 2012 at 8:08

[GoogleCodeExporter]

In this patch comments from #32 are addressed.
@comment#31: this method is not GPU accelerated.

Original comment by iohan...@gmail.com on 25 Oct 2012 at 10:01

Attachments:

• osr2.patch

[GoogleCodeExporter]

Thanks for the updated patch. Some comments:

1. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#1290

+ ///
+ // Notify browser that widget was resized. If window rendering is disabled,
+ // the browser will call CefRenderHandler::GetViewRect and
+ // CefRenderHandler::OnPaint in order to draw the newly rendered view to fit
+ // the new widget size
+ ///
+ /*--cef()--*/
+ virtual void WasResized() =0;

Is it ever useful to call this method when window rendering is enabled? If not, 
we should say "This method is only used when window rendering is disabled" as 
we do with the other methods.

2. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#1311

+ virtual void SendKeyEvent(KeyType type, const CefKeyInfo& keyInfo,
+                           int modifiers) =0;

Use the existing CefKeyEvent type instead of copying the platform-specific 
types from CEF1. The method signature should look like: SendKeyEvent(const 
CefKeyEvent& event)

3. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#949

--- include/cef_render_handler.h (revision 0)
+++ include/cef_render_handler.h (revision 0)
@@ -0,0 +1,116 @@
+// Copyright (c) 2012 The Chromium Embedded Framework Authors. All rights
+// reserved.

All public API header files that are not copied from Chromium maintain the same 
copyright message. Please don't change it.

4. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#2234

Index: libcef/browser/backing_store_osr.cc

Instead of #ifdef'ing large parts of this file let's break it into 
backing_store_osr.cc and backing_store_osr_[win|mac|gtk].cc.

5. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#3081

+ // CefBrowserContext functions

This comment is unnecessary.

6. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#3083

+ ///
+ // For disabling window rendering call this function with |override|=true
+ // just before calling WebContents::Create. This will make
+ // CefContentBrowserClient::OverrideCreateWebContentsView to create
+ // a windowless WebContentsView object
+ ///

Adding /// around comments is to assist the documentation generator tool and 
isn't necessary outside of public API header files.

7.http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=518
0034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#2677

+ if (CefBrowserHostImpl::IsWindowRenderingDisabled(windowInfo)
+ && !client->GetRenderHandler().get()) {

Operators like && should be on the proceeding line.

8. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#3173

+ 'defines': [
+ # Define to allow disabling window rendering on Windows only
+ 'OFF_SCREEN_RENDERING',
+ ],

Use existing OS platform defines instead of adding a new #define. Use the gyp 
configuration to only include files like render_widget_host_view_osr on 
platforms that support it.

9. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#2353

Index: libcef/browser/browser_host_impl_mac.mm
===================================================================
--- libcef/browser/browser_host_impl_mac.mm (revision 877)
+++ libcef/browser/browser_host_impl_mac.mm (working copy)

Also add stubs for new methods to browser_host_impl_gtk.cc.

10. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#2454

+
+ virtual content::WebContentsView* OverrideCreateWebContentsView(
+ content::WebContents* web_contents,
+ content::RenderViewHostDelegateView** rvhdv) OVERRIDE;
+

Maintain the method declaration ordering from the parent interface 
(content::ContentBrowserClient).

11. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#1649

+ // This Id should be a valid windows handle.
+ // RenderWidgetHostImpl::GetWebScreenInfo rely on it to optain
+ // screen/monitor info.
+ return reinterpret_cast<gfx::NativeViewId>(browser_impl_->GetWindowHandle());

What happens if GetWindowHandle() returns NULL? Maybe we need to fail early if 
no CefWindowInfo.parent_window is specified.

12.http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51
80034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#1745

+void CefRenderWidgetHostViewOSR::DidUpdateBackingStore(
+  const gfx::Rect& scroll_rect, int scroll_dx, int scroll_dy,
+  const std::vector<gfx::Rect>& copy_rects) {
+    if (!scroll_rect.IsEmpty()) {

Wrong indentation here. Should be 4 spaces on the method parameters and 2 
spaces on the implementation.

13. 
http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=51800
34000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282#1872

+ for (size_t i = 0; i < copy_rects.size(); ++i) {
+ const gfx::Rect rc = client_rect.Intersect(copy_rects[i]);
+ rcList.push_back(CefRect(rc.x(), rc.y(), rc.width(), rc.height()));
+ }
+
+ for (size_t i = 0; i < pending_update_rects_.size(); ++i) {
+ const gfx::Rect rc = client_rect.Intersect(pending_update_rects_[i]);
+ rcList.push_back(CefRect(rc.x(), rc.y(), rc.width(), rc.height()));
+ }

Use SkRegion and SkRegion::Cliperator to create a minimal set of 
non-overlapping rects. See for example WebWidgetHost::Paint() in CEF1.

Original comment by magreenb...@gmail.com on 15 Nov 2012 at 5:28

[GoogleCodeExporter]

Thanks for comments.
I attached a new patch containing the requested changes.

Original comment by iohan...@gmail.com on 19 Nov 2012 at 5:03

Attachments:

• osr3.patch

[GoogleCodeExporter]

@comment#36: Thanks, committed in revision 919 with the following changes:

1. Execute the new CefBrowserHost methods on the UI thread.
2. Minor changes to platform defines and GYP configuration.
3. Minor style and documentation changes.

Notes:

- Popup menus, drag&drop and GPU acceleration are not currently supported.
- Testing is enabled in cefclient by passing the "off-screen-rendering-enabled" 
command-line flag.

Thread related to popup menu support: 
https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-dev/
SzA0Jze7o3Q

Are you planning to work on support for other platforms?

Original comment by magreenb...@gmail.com on 21 Nov 2012 at 12:43

[GoogleCodeExporter]

@comment#36
Thank you for submitting the patch.
I plan to work on off-screen rendering support for Mac, but I don't have a 
schedule for this yet.
Popup menus are very important to fully cover the basic rendering 
functionality. I can make a small patch in CEF for chromium changes until they 
get shipped in chromium and move forward with supporting popup menus in 
off-screen rendering mode. What is your opinion on this?

Original comment by iohan...@gmail.com on 21 Nov 2012 at 9:11

[GoogleCodeExporter]

@comment#38: Yes, let's patch Chromium for the time being to support popups.

Original comment by magreenb...@gmail.com on 21 Nov 2012 at 2:25

[GoogleCodeExporter]

Great work guys! With the soon-to-be-done popup menu support, does that mean 
off-screen rendering in CEF3 is on par with CEF1?

Original comment by dreijer...@gmail.com on 21 Nov 2012 at 2:43

[GoogleCodeExporter]

@comment#40: For Windows, yes. Other platforms are not yet supported.

Original comment by magreenb...@gmail.com on 21 Nov 2012 at 2:45

[GoogleCodeExporter]

Thanks iohanson for the patch! awesome work!

Question: Do you plan adding GPU acceleration support in offscreen mode (see 
comment @25 about that posibility)?

Do you think is it possible to do such a thing?

Thanks and best regards.

Original comment by efre...@gmail.com on 21 Nov 2012 at 4:02

[GoogleCodeExporter]

@comment #42
Unfortunately I haven't had the chance to investigate the hardware path for 
off-screen rendering and I couldn't tell weather this is possible or not at 
this time. I'd like to have the rudimentary support first for both mac & 
windows, covering most use cases. After this happen we will definitely look 
together for performance improvements.

Original comment by iohan...@gmail.com on 22 Nov 2012 at 12:11

[GoogleCodeExporter]

@comment #43
Thank you... that would be a great addition.

@commnet #37
Marshall, Off-screen rendering have been one of the most starred issues in 
CEF3. Now that is commited... Whouldn't it be a good time to release a new 
build on CEF3 with offscreen test?

Regards.

Original comment by efre...@gmail.com on 22 Nov 2012 at 12:37

[GoogleCodeExporter]

> Marshall, Off-screen rendering have been one of the most starred issues in 
CEF3. Now that is commited... Whouldn't it be a good time to release a new 
build on CEF3 with offscreen test?

+1 for this!

Original comment by dreijer...@gmail.com on 22 Nov 2012 at 12:43

[GoogleCodeExporter]

agree, I'd also like a release or at least a beta to play with (so we can also 
early detect any issues)! Great work, thanks!

Original comment by asktheg...@gmail.com on 22 Nov 2012 at 6:56

[GoogleCodeExporter]

Are there any plans to add offscreen rendering for Linux?

Original comment by goo...@dav1d.de on 28 Nov 2012 at 10:42

[GoogleCodeExporter]

Current off-screen rendering implementation on Windows, does not support alpha 
channel, BackingStoreOSR::PaintToBackingStore() use StretchDIBits() to copy 
buffer, and the alpha channel is lost and valued 0.

Original comment by Zhaojun....@gmail.com on 3 Dec 2012 at 1:43

[GoogleCodeExporter]

@comment #47: Unfortunately, no plans for Linux on my side.

@comment #48: RGB bits received from the renderer appear to have the alpha 
blending factor already applied.

Original comment by iohan...@gmail.com on 4 Dec 2012 at 4:23

[GoogleCodeExporter]

I would like to start working on the Mac implementation. If anyone already did 
some work on it, please comment so I don't duplicate work.

Thanks

Original comment by ol...@adobe.com on 4 Dec 2012 at 9:44