[webkit-dev] WebKit GPU rendering possibility

Thu Nov 3 00:26:35 PDT 2016

El jue, 03-11-2016 a las 06:58 +0000, Rogovin, Kevin escribió:
> 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).

That makes me wonder, would it be possible to add a new cairo backend
based on FastUIDraw? That would make very easy to try it out with the
current GraphicsContext cairo backend.

> 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 http
> s://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.

This looks really interesting, I think the GTK+ port could benefit from
this if it eventually can be used as a cairo replacement.

> 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>
> 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/01or
> g/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
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>  
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev