Comparison to using CEF

[Callum Prentice]

https://bitbucket.org/lindenlab/dullahan

I've been working on a C++ Windows, Mac and Linux(kind of) library that makes use of the Chromium Embedded Framework (the version like Chrome 57 currently) and allows you to render web content to memory as well as inject synthesized keyboard and mouse events into a page.  We use it to update textures that are then used in our OpenGL based application.

Is the headless mode of Chrome something we might consider replacing it with and what, if any, are the piece we wouldn't be able to do.

A brief comparison in this context would be very much appreciated.

[Sami Kyostila]

Headless Chrome is potentially a candidate for what you're doing and the features you mentioned are supported, although we're explicitly not targeting use cases where headless becomes an actually visible widget in a UI -- libraries like CEF are probably a better fit for that. For instance, CEF might let you use GPU hardware acceleration which currently isn't the case with Headless Chrome.

- Sami

--
You received this message because you are subscribed to the Google Groups "headless-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to headless-dev...@chromium.org.
To post to this group, send email to headle...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/headless-dev/2abfee4f-3e65-4fbf-b72b-878bf2cad5e4%40chromium.org.

[Callum Prentice]

Understood and thanks Sam.  

Just to be clear, the headless Chrome would never become visible - it would just be rendering content somewhere that would be captured and used in the target application.  Lack of GPU is okay - I had to turn that off in CEF too recently. 

On Tue, Apr 18, 2017 at 11:35 AM, Sami Kyostila <skyo...@chromium.org> wrote:

Headless Chrome is potentially a candidate for what you're doing and the features you mentioned are supported, although we're explicitly not targeting use cases where headless becomes an actually visible widget in a UI -- libraries like CEF are probably a better fit for that. For instance, CEF might let you use GPU hardware acceleration which currently isn't the case with Headless Chrome.

- Sami

to 13. huhtik. 2017 klo 0.55 Callum Prentice <cal...@gmail.com> kirjoitti:

https://bitbucket.org/lindenlab/dullahan

I've been working on a C++ Windows, Mac and Linux(kind of) library that makes use of the Chromium Embedded Framework (the version like Chrome 57 currently) and allows you to render web content to memory as well as inject synthesized keyboard and mouse events into a page.  We use it to update textures that are then used in our OpenGL based application.

Is the headless mode of Chrome something we might consider replacing it with and what, if any, are the piece we wouldn't be able to do.

A brief comparison in this context would be very much appreciated.

--
You received this message because you are subscribed to the Google Groups "headless-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to headless-dev+unsubscribe@chromium.org.

[Abhishek Azad]

Hi Sam

We are using CEF to render frames to a shared location which are then displayed by our application. Looks like we can also use headless chrome to render frames to some location and then read from there, I am unable to figure out how we can achieve that using Headless Chrome, could you please provide some pointers in this direction ?

Thanks

Abhishek

On Wednesday, April 19, 2017 at 2:37:22 AM UTC+5:30, Callum Prentice wrote:

Understood and thanks Sam.  

Just to be clear, the headless Chrome would never become visible - it would just be rendering content somewhere that would be captured and used in the target application.  Lack of GPU is okay - I had to turn that off in CEF too recently. 

On Tue, Apr 18, 2017 at 11:35 AM, Sami Kyostila <skyo...@chromium.org> wrote:

Headless Chrome is potentially a candidate for what you're doing and the features you mentioned are supported, although we're explicitly not targeting use cases where headless becomes an actually visible widget in a UI -- libraries like CEF are probably a better fit for that. For instance, CEF might let you use GPU hardware acceleration which currently isn't the case with Headless Chrome.

- Sami

to 13. huhtik. 2017 klo 0.55 Callum Prentice <cal...@gmail.com> kirjoitti:

https://bitbucket.org/lindenlab/dullahan

I've been working on a C++ Windows, Mac and Linux(kind of) library that makes use of the Chromium Embedded Framework (the version like Chrome 57 currently) and allows you to render web content to memory as well as inject synthesized keyboard and mouse events into a page.  We use it to update textures that are then used in our OpenGL based application.

Is the headless mode of Chrome something we might consider replacing it with and what, if any, are the piece we wouldn't be able to do.

A brief comparison in this context would be very much appreciated.

--
You received this message because you are subscribed to the Google Groups "headless-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to headless-dev...@chromium.org.

[Sami Kyostila]

There's no way to render into shared memory in headless currently, but we are working to make rendering and capturing screenshots more efficient in general. It wouldn't be too difficult to expose a shared memory framebuffer if we wanted to.

- Sami

[Abhishek Azad]

Hi Sami

Thanks for your prompt response. I work with Adobe and we are currently exploring if we can use as headless chrome as a replacement for CEF. We would want to use headless chrome to render open web content to a shared memory buffer and marshal events to it using IPC. Could you please consider exposing a shared memory framebuffer ?

This would also mean that we will bundle chrome's installers (or ask users to install chrome) with acrobat/reader installation which will help expanding chrome's installation base. Please look forward to a communication from our official Email channel regarding this. 

Thanks In Advance.

Abhishek
Acrobat Desktop Team, Adobe

[Sami Kyostila]

Hi Abhishek,

Just to make sure I understand, in this configuration you'd launch Chrome with --headless and use some new DevTools command to direct software rendering to a named shared memory segment -- is that right?

- Sami

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/headless-dev/a635366b-b643-4b2b-9c54-781297a9a13e%40chromium.org.

[Abhishek Azad]

Hi Sami

That's is correct. Our assumption is that we would be able to interact with chrome via sending and receiving events from headless instance of chrome. (Maybe with devtools CPP Apis, currently existing or new ones)

[Abhishek Azad]

Hi Sami

That's is correct. Our assumption is that we would be able to interact with chrome via sending and receiving events from headless instance of chrome. (Maybe with devtools CPP Apis, currently existing or new ones)

To unsubscribe from this group and stop receiving emails from it, send an email to headless-dev+unsubscribe@chromium.org.

To post to this group, send email to headle...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/headless-dev/a635366b-b643-4b2b-9c54-781297a9a13e%40chromium.org.

--

Regards
Abhishek Azad   | +91-9355112252 | abhishe...@gmail.com

[Sami Kyostila]

It's not possible to use the C++ DevTools APIs with the release build of Chrome. Instead you can either use the DevTools protocol over a WebSocket or bundle your own copy of the C++ headless library.

- Sami

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/headless-dev/a635366b-b643-4b2b-9c54-781297a9a13e%40chromium.org.

[Abhishek Azad]

Hi Sami

Just to make sure I have understood this correctly. Given headless chrome starts rendering to a shared buffer, we should be able to interact with it using Devtools protocol over a WebSocket from our desktop application ?

On Saturday, May 20, 2017 at 12:34:50 AM UTC+5:30, Sami Kyostila wrote:

It's not possible to use the C++ DevTools APIs with the release build of Chrome. Instead you can either use the DevTools protocol over a WebSocket or bundle your own copy of the C++ headless library.

- Sami

pe 19. toukok. 2017 klo 20.00 Abhishek Azad  kirjoitti:

Hi Sami

That's is correct. Our assumption is that we would be able to interact with chrome via sending and receiving events from headless instance of chrome. (Maybe with devtools CPP Apis, currently existing or new ones)

On Sat, May 20, 2017 at 12:22 AM, Sami Kyostila <skyo...@chromium.org> wrote:

Hi Abhishek,

Just to make sure I understand, in this configuration you'd launch Chrome with --headless and use some new DevTools command to direct software rendering to a named shared memory segment -- is that right?

- Sami

[Sami Kyostila]

Right, although I think we need to consider a bit whether this is a use case headless Chrome should be supporting.

- Sami

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/headless-dev/6ee18240-e61f-41f4-a3cd-5b09033887f8%40chromium.org.