How rendering works in Blink

[Craig Francis]

Not sure if anyone can point me in the right direction on how Blink renders a page.

I'm trying to find a way to get a full page screenshot, something that is currently not possible with the JavaScript API chrome.tabs.captureVisibleTab:

https://code.google.com/p/chromium/issues/detail?id=469663

At a guess, it looks like "CopyFromCompositingSurface" might be the issue... and considering the browser must know the size of the page for the scroll bars, maybe there is a way to get the rendered output some other way?

[Philip Rogers]

I wrote a wrapper around content shell last week that does exactly this: https://github.com/progers/content-screenshot

This is not official or supported (patches welcome?), but it may work for you. It reuses our layout test code (part of content shell) and dumps a png from a given html/svg file or url.

[Craig Francis]

On 26 Mar 2015, at 17:27, Philip Rogers <p...@chromium.org> wrote:

I wrote a wrapper around content shell last week that does exactly this: https://github.com/progers/content-screenshot

Thanks Philip,

That looks like the right direction.

So content_shell is a wrapper (outside of chrome), that needs you to specify a width/height of a window (aka viewport?)... which is set with --content-shell-host-window-size=800x600, and used with:

/src/content/shell/browser/shell.cc

PlatformInitialize(ShellDefaultSize());

And in the same way as chrome.tabs.captureVisibleTab, it also works with a RenderWidgetHostView

host_view = web_contents_->GetRenderWidgetHostView();

But it looks like CreateShell() is basically creating a new window of the specified size... which seems a little wasteful if we consider that a RenderWidgetHostView already exists, and is available to the Chrome extensions (indirectly)... and that presumably cannot be resized without changing the browser window size? which might upset the user.

As a side note, on line 25 of your script, can you check --pixel-test, it seems to begin with a single quote for some reason (does not seem to break anything though).

https://github.com/progers/content-screenshot/blob/master/contentScreenshot.py#L25

But that still confirms the content module (aka /src/content/) contains everything todo with rendering:

https://www.chromium.org/developers/content-module

And I should probably be looking at its API, defined in "/src/content/public/":

https://www.chromium.org/developers/content-module/content-api

Which does define "CopyFromBackingStore"... part of RenderWidgetHost.

So can anyone confirm if the RenderWidgetHost is limited to a viewport of some kind? and if so, is there a parent to it? so we can get the whole page?

In passing, I did notice a couple of places that mentioned:

RenderViewImpl::GetWindowSnapshot

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/o2aUtFAIlyQ

But I'm not sure what a RenderView is compared to a RenderWidgetHost.

And at the same time, this does seem to be a re-occuring problem, so maybe this isn't going to be easy to fix:

https://code.google.com/p/chromium/issues/detail?id=155101

Craig

[Siva Kumar Gunturi]

Hi Craig,

CopyFromCompositingSurface can only capture the visible( the contents available to compositor) area of the screen.
This internally composites and readback from a texture, scales it and gives back the desired output image.
As we read the snapshot from gpu, while using this, the compositor maintains only a portion of page to
display to user , based on the change in viewport the remaining portions are composited , so there is no direct way
we can get the entire page using this api.

We can do it via render process , by drawing the frame to a bitmap, but there we may not get the accelerated elements in the snapshot
you are going to capture.

Regards,
Siva

[Craig Francis]

On 8 April 2015 at 14:14, Siva Kumar Gunturi <sivag...@chromium.org> wrote:

We can do it via render process , by drawing the frame to a bitmap, but there we may not get the accelerated elements in the snapshot you are going to capture.

Thanks Siva,

I realise you have commented on issue 469663 (thanks for that), so this might be fixable though your changes related to copyFromCompositingSurface.

But where you say it might not get the accelerated elements... is that "at all" (e.g. leaving gaps in the bitmap output), or just in a fast way (resulting in the render process having to work harder to render everything).

If it's the latter, then that probably won't be an issue... especially for my use case (and pretty much all of the others I've seen)... where the current approach seems to involve scrolling around the page, and taking many screenshots (very slow and buggy).

Craig

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