search

chromiumembedded / cef

Chromium Embedded Framework (CEF). A simple framework for embedding Chromium-based browsers in other applications.
https://bitbucket.org/chromiumembedded/cef/
Other
3.41k stars 468 forks source link

CEF3: Add off-screen rendering support #518

Closed magreenblatt closed 12 years ago

magreenblatt commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

Original comment by Anonymous.

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

very important and useful feature!

magreenblatt commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

Original comment by Anonymous.

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

Very useful functionnality

magreenblatt commented 12 years ago

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 commented 12 years ago

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:

Methods that the browser provides:

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

Original comment by Anonymous.

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

Awesome, thanks for doing this!

magreenblatt commented 12 years ago

Original comment by Anonymous.

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

any news?

magreenblatt commented 12 years ago

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 commented 12 years ago

Original comment by Anonymous.

Comment 31. originally posted by efrencd on 2012-10-21T14:46:27.000Z:

@ comment 30: Nice job!

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

Regards!

magreenblatt commented 12 years ago

Comment 32. originally posted by magreenblatt on 2012-10-22T21:59:45.000Z:

@ commentcomment 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=5180030000&name=osr1.patch&token=9vi5qQZELd60Saw1\_Fh\_\_F5BrtI%3A1350941942419comment 12.99

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?

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180030000&name=osr1.patch&token=9vi5qQZELd60Saw1\_Fh\_\_F5BrtI%3A1350941942419comment 18.93

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.

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 33. originally posted by iohanson on 2012-10-23T08:08:15.000Z:

@ commentcomment 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
magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 34. originally posted by iohanson on 2012-10-25T22:01:17.000Z:

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

magreenblatt commented 12 years ago

Comment 35. originally posted by magreenblatt on 2012-11-15T17:28:57.000Z:

Thanks for the updated patch. Some comments:

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 12.90

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.

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 13.11

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

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 94.9

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

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 22.34

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.

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 30.81

This comment is unnecessary.

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 30.83

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=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 26.77

Operators like && should be on the proceeding line.

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 31.73

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.

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 23.53

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.

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 24.54

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

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 16.49

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=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 17.45

+void CefRenderWidgetHostViewOSR::DidUpdateBackingStore(

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

  1. http://code.google.com/p/chromiumembedded/issues/attachmentText?id=518&aid=5180034000&name=osr2.patch&token=iUXy1X8IEZIZKKPpDXudetYZ4AE%3A1352995743282comment 18.72

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

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 36. originally posted by iohanson on 2012-11-19T17:03:53.000Z:

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

magreenblatt commented 12 years ago

Comment 37. originally posted by magreenblatt on 2012-11-21T00:43:01.000Z:

@ commentcomment 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:

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?

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 38. originally posted by iohanson on 2012-11-21T09:11:04.000Z:

@ commentcomment 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?

magreenblatt commented 12 years ago

Comment 39. originally posted by magreenblatt on 2012-11-21T14:25:12.000Z:

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

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 40. originally posted by dreijerbit on 2012-11-21T14:43:00.000Z:

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?

magreenblatt commented 12 years ago

Comment 41. originally posted by magreenblatt on 2012-11-21T14:45:09.000Z:

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

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 42. originally posted by efrencd on 2012-11-21T16:02:25.000Z:

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.

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 43. originally posted by iohanson on 2012-11-22T00:11:19.000Z:

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

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 44. originally posted by efrencd on 2012-11-22T00:37:25.000Z:

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

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

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 45. originally posted by dreijerbit on 2012-11-22T00:43:53.000Z:

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!

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 46. originally posted by askthegimp on 2012-11-22T18:56:32.000Z:

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!

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 47. originally posted by google@dav1d.de on 2012-11-28T10:42:15.000Z:

Are there any plans to add offscreen rendering for Linux?

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 48. originally posted by Zhaojun.Meng on 2012-12-03T01:43:10.000Z:

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.

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 49. originally posted by iohanson on 2012-12-04T16:23:04.000Z:

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

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

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 50. originally posted by olaru@adobe.com on 2012-12-04T21:44:50.000Z:

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

magreenblatt commented 12 years ago

Original comment by Anonymous.

Comment 51. originally posted by Zhaojun.Meng on 2012-12-07T01:54:01.000Z:

I add transparent to element, like this: , but the bitmap got from render process is opaque.
How can I support transparent background? Do I need to change code in content/renderer?