Gpu rasterization is enabled in chrome 37 in android

[rbha...@nvidia.com]

I see that Gpu rasterization is enabled in chrome 37 in android. I would like to know which all HTML elements like text, images, etc are rasterized by gpu ? I can see images are still using webkit decoders and being rasterized by CPU. 

Also there are image codecs available in skia, So is there any future plans to enable gpu rasterization of images ?

[Vangelis Kokkevis]

The conditions under which GPU rasterization is triggered are outlined in this page:

http://www.chromium.org/developers/design-documents/chromium-graphics/how-to-get-gpu-rasterization

Once a page is in GPU rasterization mode, we draw its entire contents on the GPU. That includes HTML elements, images, text, paths, etc. etc.

There are a couple of details worth noting:

* Text: For text we currently use a bitmap-based glyph cache. We're also experimenting with Distance Field based text, currently triggerable via a command-line flag.

* Images: Images are decoded on the cpu and uploaded as RGBA textures. In ToT we have an experimental flag to allow decoding of some jpeg images to YUV and doing the color space conversion in a shader to speed up decoding and uploads.

* Paths: Some path objects are drawn via shaders directly on the GPU while others (mostly depending on complexity) require a software rasterization step. Pages with too many complex paths currently get "vetoed" and fall back to the software raster backend. There is ongoing work to add support for NVIDIA's NVPR extension. We're also investigating alternative techniques for moving more of the path rendering logic to the GPU.

Hope this helps. 

Vangelis

On Tue, Oct 7, 2014 at 10:40 PM, <rbha...@nvidia.com> wrote:

I see that Gpu rasterization is enabled in chrome 37 in android. I would like to know which all HTML elements like text, images, etc are rasterized by gpu ? I can see images are still using webkit decoders and being rasterized by CPU. 

Also there are image codecs available in skia, So is there any future plans to enable gpu rasterization of images ?

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

[Kenneth Rohde Christiansen]

Why is this only enabled for viewports allowing zooming? Disabling zooming seems like a subset of allowing it and currently the Polymer Calculator demo is slower than say Topeka as its disabling it.

Kenneth

--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone  +45 4294 9458 ﹆﹆﹆

[Kenneth Rohde Christiansen]

Maybe I am wrong, http://www.chromium.org/developers/design-documents/chromium-graphics/how-to-get-gpu-rasterization doesn't talk about not disabling zooming, but the video from Nat Duca did. It talked about an exact match with the magic viewport.

Maybe someone could clarify

Kenneth

[rbha...@nvidia.com]

Thanks Vangelis for useful info.

Still need to discuss more about jpeg image decoding. Now a days most of the chip vendors have dedicated hardware for jpeg decoding which gives RGBA output, so in this case, can you please give some pointers how this will fit in current flow? in this case, we can decode jpeg image directly in browser/gpu process which would eliminate RGBA texture upload.

[Manfred Ernst]

The information on the web page you quoted is up-to-date. Your need a viewport with width=device-width and minimum-scale=1.0 to trigger GPU rasterization.

[Vangelis Kokkevis]

On Thu, Oct 9, 2014 at 3:06 AM, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

Maybe I am wrong, http://www.chromium.org/developers/design-documents/chromium-graphics/how-to-get-gpu-rasterization doesn't talk about not disabling zooming, but the video from Nat Duca did. It talked about an exact match with the magic viewport.

Maybe someone could clarify

The confusion comes from the fact that in Chrome 36, the first release that supported GPU rasterization, we further restricted to pages with maximum-scale=1.  In Chrome 37 (current stable) we removed that restriction.

[Vangelis Kokkevis]

On Thu, Oct 9, 2014 at 4:37 AM, <rbha...@nvidia.com> wrote:

Thanks Vangelis for useful info.

Still need to discuss more about jpeg image decoding. Now a days most of the chip vendors have dedicated hardware for jpeg decoding which gives RGBA output, so in this case, can you please give some pointers how this will fit in current flow? in this case, we can decode jpeg image directly in browser/gpu process which would eliminate RGBA texture upload.

At a minimum we'd need driver support to be able to upload encoded jpg image data into a texture and sample out of it in RGBA. Is there a standard extension for this that's widely available? 

[Vangelis Kokkevis]

On Fri, Oct 10, 2014 at 6:40 AM, <rbha...@nvidia.com> wrote:

No, I'm not talking about image decode by gpu. Instead a special hardware can decode image into RGBA buffer. This hardware can be accessed through libjpg_turbo, keeping decode APIs intact.

but due to sandbox restriction, access to hardware is not possible in renderer process. So need some input about how to plugin hardware image decoding in gpu rasterization pipeline.

Will the resulting decoded image reside in system memory then and will have to be uploaded to texture memory like other images do via a glTexImage2D call? If that's so, then my guess is that we'll want to spec a CHROMIUM extension in the command buffer to allow uploading jpg image contents to a texture. The client side code will copy the jpg image to shared memory and the service side will be responsible for doing the conversion and the actual upload from the resulting RGBA buffer.

What platforms is this functionality available on?