Help me Understand Skia Rasterization

[Alireza Khadem]

Hi All,

I am new to the browser world. I am reading Skia source code in the Chromium project and I am having a hard time mapping the Chromium rendering pipeline to the Skia source code. I am not sure if this forum is a good place for asking these questions, but since my questions are more related to the Skia, I preferred to ask them here. I appreciate it if you let me know whether my understanding is correct, and refer me to any documents or the source code where I can answer my questions.

I know that Chrome, in the Paint stage, records a list of drawing instructions (like a triangle) from layout objects, and outputs paint artifacts (display item list).

The next stage in the Chromium pipeline is the Raster stage, where Chrome executes paint artifacts of the tiles and produces bitmap.

Now I want to know how is this mapped to the Skia source code. Skia has a Raster Pipeline (SkRasterPipeline class) which contains different stages (defined in src/core/SkRasterPipeline.h). But what component is responsible to convert each paint artifact to a Skia pipeline stage?

Chromium supports hardware compositing. But I don't understand which part of the Skia operations are offloaded to the GPU. In other words, if compositing is accelerated, do Skia pipeline stages run on GPU instead of the CPU? If not, what part of the rasterization is hardware accelerated?

Thank you in advance for any help or information,

- Alireza

[John Stiles]

> But what component is responsible to convert each paint artifact to a Skia pipeline stage?

You should take a look at SkBlitter.cpp (SkBlitter::Choose) seand SkRasterPipelineBlitter.cpp. This is where the SkPaint gets turned into raster pipeline ops and gets prepared to execute.

> In other words, if compositing is accelerated, do Skia pipeline stages run on GPU instead of the CPU?

SkRasterPipeline is only used in software rasterization. When we are drawing to a GPU surface, we have a totally different path for converting the SkPaint into real work. See SkGr.cpp (SkPaintToGrPaint) for how that is done. (Coincidentally, we are also working on a new version of the GPU code that works differently still.)

[Brian Osman]

More generally - things like the SkRasterPipeline are really implementation details of the CPU rasterization. Chrome (and all other projects) interacts with Skia using the public API. The major pieces are:

1) Create a SkSurface. There are factories for creating either CPU-backed or GPU-backed surfaces. The surface itself determines which backend is used when drawing to that surface.

2) Get the SkCanvas from the surface - this is the primary public interface of Skia. SkCanvas has all of the drawing methods. When you issue a draw command to the SkCanvas, it gets dispatched to the canvas' SkDevice (an internal type). The device comes from the surface, and there are separate C++ SkDevice classes for the CPU and GPU. Each device then has a large amount of code it uses to implement all of the drawing algorithms.

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/ff368cd2-b59e-4478-9345-10dcf06850cen%40googlegroups.com.

[K. Moon]

Your question might be better directed to the chromium-dev mailing list, as it's more about how Chromium uses Skia than about Skia itself. Specifically, you should look at how //cc/paint interacts with SkCanvas. You may also want to read about the "Life of a Pixel" at https://www.chromium.org/developers/design-documents/. 

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CAMcBjo4%2BK5Vsr0DgQpbzkt0PYZVCj-_yT3Z8xw%2BCwHg_W2ZELA%40mail.gmail.com.

[Alireza Khadem]

Hi Everyone,

Thanks for providing a lot of useful information.

@John Stiles

> When we are drawing to a GPU surface, we have a totally different path for converting the SkPaint into real work.

I am specifically interested in the use of vector processing in Skia, especially when hardware compositing is enabled in the Chromium project.

So I profiled chromium with hardware compositing and found that many Skia functions (that use vector operations) are called in this file (opts/SkRasterPipeline_opts.h).

I thought that these functions are SkRasterPipeline stages but it seems that this is not the case.

If Skia uses GPU device, why would it execute opt stages on CPU rather than offloading to the GPU?

Would you please provide more information about the files in the opts directory and their usage when Skia uses GPU rasterization?

In addition, do you have more insights on how Skia takes advantage of vector operations for accelerating the rasterization? 

@Brian Osman

> When you issue a draw command to the SkCanvas, it gets dispatched to the canvas' SkDevice (an internal type). The device comes from the surface, and there are separate C++ SkDevice classes for the CPU and GPU. Each device then has a large amount of code it uses to implement all of the drawing algorithms.

So I think based on your explanation, there is a device-agnostic front-end (SkCanvas) that receives paint operations, does some processing, and dispatches them to the back-end. What are the responsibilities of this frond-end (SkCanvas) and what kind of processing does it do?

There is a device-specific back-end (SkDevice) that is responsible to send the instructions to the device (e.g., GPU), and GPU renders them. I think that all the files under the gpu directory provide raster implementation for the GPU SkDevice. Right?

I am trying to understand an overview of both front-end and back-end processing. What operations each of these stages are responsible for?

I found many drawing algorithms in gpu/Device.cpp which looks like it is at the end of the back-end stage where operations are sent to the GPU for execution. Right?

Best,

- Alireza