[webkit-dev] WebKit GPU rendering possibility

Wed Nov 2 23:58:37 PDT 2016

Hi!

Question answers:

1.      Currently FastUIDraw has a backend to OpenGL 3.3 and OpenGL ES 3.0. One of its design goals is to make it not terribly awful to write a backend to different 3D API’s.

2.      I think I was unclear in my video. I have NOT migrated ANY UI rendering library to use Fast UI Draw. What I have done is made a demo (painter-cells) and ported that demo to Fast UI Draw, Cairo, Qt’s QPainter and SKIA. The diffs between the ports is almost trivial (it really is just using those different rendering API’s).

3.      There are a few areas:

a.      Reduce some render to offscreen buffers. When I worked with WebKit YEARS ago, I saw a few instances of rendering to texture that are unnecessary and even harm performance for GPU rendering. The first example was where a brush pattern with an image and/or gradient applied is to be drawn tiled across an area. WebKit (at that time) first drew a single instance of that pattern to an image, then drew that image tiled. For GPU renderers we can (very easily) just do the repeat pattern (of both original image and gradient) from a shader. Another instance happens at RenderLayer where a new GraphicsContext “layer” is started on a transformation that has rotation or perspective. For FastUIDraw, this is not necessary, though if a layer is transparent, then it is.

b.      In addition, FastUIDraw has an interface so that if “what” is drawn is unchanged but the “how” changes, then a caller can cache the “what” to send to the GPU. To be explicit, “what” to draw is essentially attributes and indices and those values do NOT depend on the state of “how” to draw. Examples of “how” to draw: current transformation, brush to apply, clipping applied, stroking parameters (including dash pattern) and blending mode. I admit that I am quite proud of being able to use the same attributes an indices even if stroking parameters (stroking width, miter limit and dash pattern) change. Text rendering “what” to draw does depend on what glyphs one wants to use. Specifically, if drawing coverage font glyphs, then attributes and indices values change if one wants to draw the glyph biffer, but for the GPU rendered glyphs they do not.

4.      The renderer implements full 3x3 transformations. However, the renderer does NOT implement out-of-order transparency. For a GPU, a 3x3 transformation is cheap (naturally!). The renderer does handle, with a very little additional overhead changing clipping even between nasty rotations or perspective changes. The demo painter-cells deliberately pushes and does lots of nasty clipping and the performance impact of it on FastUIDraw is very small.

5.      Drawing text is a right pain in the rear. Currently, FastUIDraw has 3 methods to draw text: coverage, distance field and an original GPU algorithm that I devised for another open sourced project years ago. Coverage is needed when glyphs are drawn small and hinting becomes important. The original GPU algorithm keeps corners sharps and does a computation in the fragment shader to compute a coverage value. Distance field is a fall back which has render quality issues (namely corners are rounded) but is very, very cheap. I want to write an additional glyph renderer that is much faster than the original GPU method and keeps corners sharp. This new one is to use the ideas found in https://github.com/Chlumsky/msdfgen but I have a way to make the distance field generation much, much faster and handle natively cubics (instead of breaking cubics into quadratics)

For convenience, below is a list of features FastUIDraw implements:

1.      3x3 transformation matrix

2.      path stroking with anti-aliasing

a.      dashed stroking too

b.      miter, rouned, bevel joins

c.      flat, square and rounded caps

3.      path filling against an arbitrary fill rule

4.      “brush”

a.      linear gradients

b.      two point conical gradients (I call these radial gradients)

c.      images

                                                    i.     nearest, bilinear and bicubic filtering

5.      Clipping

a.      clipIn against rect or filled path (with arbitrary fill rule)

b.      clipOut against path (with arbitrary fill rule)

6.      Glyph rendering

a.      coverage fonts

b.      1-channel distance field

c.      curve-pair analytic (original algorithm)

7.      all 12 Porter-Duff blend modes

However, I still have work to do:

1.      anti-alias path fills

2.      anti-alias clipping

3.      more glyph rendering work

4.      some optimizations related to culling on path-fills

5.      dash pattern adjustments from contour length as found in https://www.w3.org/TR/svg-strokes/

6.      the analog of GraphicContext’s begin/endTransparencyLayer

7.      The blend/combine/transfer modes of W3C that are not from Porter-Duff.

At this point, I need to garner interest to be able to get time to work on this project at my employer. The stronger the enthusiasm I can get the better my chances for continuing the work.

Best Regards,
-Kevin Rogovin

From: Myles C. Maxfield [mailto:mmaxfield at apple.com]
Sent: Thursday, November 3, 2016 1:30 AM
To: Rogovin, Kevin <kevin.rogovin at intel.com>
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] WebKit GPU rendering possibility

Hello,

This is certainly interesting work! I have a few questions about the approach of this renderer.

1. What API is this on top of? OpenGL? Metal? Vulkan? Raw GPU commands[1]?
2. You mention in your video that you have already migrated Cairo on top of your new tech. Traditionally, a web engine is divorced from a 2D rendering engine such as Cairo. Why can’t the ports of WebKit which use Cairo get this new tech without any change?
3. What sort of API changes do you have in mind to make GraphicsContext adopt?
4. Out of curiosity, does the renderer implement 3D transforms? Did you have to implement 3-D triangle subdivision along intersections (perhaps for order-independent transparency)?
5. Which algorithm did you choose to draw text?

Historically, the WebKit team has hesitated to allow experiments in the OpenSource repository. Traditionally, this sort of exploratory work is done in a branch, and only after it has proved to be an improvement, the work is adopted on trunk.

Thanks,
Myles

[1] https://01.org/linuxgraphics/documentation/hardware-specification-prms

On Nov 2, 2016, at 9:35 AM, Rogovin, Kevin <kevin.rogovin at intel.com<mailto:kevin.rogovin at intel.com>> wrote:

Hi,

I was directed here by some colleagues as this is the place to post the following to get started on the following proposal.

I have been working on an experimental 2D renderer that requires a GPU, the project is open sourced on github at https://github.com/01org/fastuidraw. I gave a talk at the X Developers Conference this year which can be seen from https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_ui_draw/ .

I made a benchmark which makes heavy use of rotations and clipping and ported to SKIA, Qt’s QPainter and Cairo. The benchmark and its ports are in the git repo linked above under the branch with_ports_of_painter-cells. It's performance advantage of FastUIDraw against the other renderers was quite severe (against Cairo and Qt's QPainter over 9 times and against SKIA about 5 times faster).

I would like to explore the option of using FastUIDraw to implement a WebCore::GraphicsContext backend for the purpose of making drawing faster and more efficient on Intel devices that are equipped with a GPU. I also think that some minor modifications to WebKit’s use of GraphicsContext will also give some benefits. I have worked on WebKit a few years ago and knew/know my way around the rendering code very well (atleast at that time).

Looking forward to collaboration,
-Kevin Rogovin

_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20161103/d002ba25/attachment.html>