[webkit-dev] WebKit GPU rendering possibility
Myles C. Maxfield
mmaxfield at apple.com
Thu Nov 3 12:42:40 PDT 2016
> On Nov 3, 2016, at 12:34 PM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>
>
>
> 03.11.2016, 22:18, "Rogovin, Kevin" <kevin.rogovin at intel.com <mailto:kevin.rogovin at intel.com>>:
>> Hi,
>>
>> What are some good 2D UI graphics benchmarks that are cross-platform-ish? I'd think I need to port them to Fast UI Draw, but that is possible.
>>
>> I am very confident that Fast UI Draw will perform at the top by a large margin. The more complicated and heavier the load, the better it will do.
>
> I would suggest you to do prototype implementation of GraphicsContext (e.g. by replacing code in GraphicsContextCairo) and run those browser performance benchmarks. If there is substantial improvement, there will be community enthusiasm.
>
As Konstantin says, browser-based benchmarks would be best, but I assumed you didn’t want to implement GraphicsContext before running benchmarks. If you do implement GraphicsContext in a branch of WebKit, there are a few browser-based performance tests which may be insightful:
CanvasMark http://www.kevs3d.co.uk/dev/canvasmark/ <http://www.kevs3d.co.uk/dev/canvasmark/>
Mozilla has a list of benchmarks https://wiki.mozilla.org/Benchmarks <https://wiki.mozilla.org/Benchmarks>
Canvas Performance Test http://www.smashcat.org/av/canvas_test/ <http://www.smashcat.org/av/canvas_test/>
Perhaps some of these could even be ported to native code so you could get up and running sooner.
—Myles
>>
>> -Kevin
>>
>> -----Original Message-----
>> From: mmaxfield at apple.com [mailto:mmaxfield at apple.com]
>> Sent: Thursday, November 3, 2016 9:07 PM
>> To: Rogovin, Kevin <kevin.rogovin at intel.com>
>> Cc: Carlos Garcia Campos <carlosgc at webkit.org>; webkit-dev at lists.webkit.org
>> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>>
>> It sounds like the primary focus of your work is improving performance. It also sounds like the only benchmark you’ve run is an artificial one that you constructed yourself.
>>
>> Given these two things, I would strongly hesitate to call our interest "significant community enthusiasm.”
>>
>> Why don’t you start by running some of the many existing graphics benchmarks with your library?
>>
>> Please correct me if my assumptions are mistaken.
>>
>> Thanks,
>> Myles
>>
>>> On Nov 3, 2016, at 12:50 AM, Rogovin, Kevin <kevin.rogovin at intel.com> wrote:
>>>
>>> Adding a new GraphicsContext is what I want to do as it seems the path of least pain and suffering. However, all the other things of a backend I do not need to do. I do not know how to add a GraphicsContext backend in terms of makefile magicks and configuration. I also do not know the plumbing for making it active. In theory, FastUIDraw's GraphicsContext will work on any platform that does OpenGL 3.3 or OpenGL ES 3.0. What is the plumbing to do this? Years ago I remember that the build configuration is what governed what backend was built... and I usually just piggy packed onto another... years ago I remember there was like an SDL style backend that did not require a large toolkit, just SDL.. is that still alive? where is it? I could piggy back the work there if it still is alive...
>>>
>>> Also, to get permission to do this work, I need significant community enthusiasm otherwise I will not be able to justify the large amount of work needed. This is another area where I need a great deal of help.
>>>
>>> Best Regards,
>>> -Kevin Rogovin
>>>
>>> -----Original Message-----
>>> From: Carlos Garcia Campos [mailto:carlosgc at webkit.org]
>>> Sent: Thursday, November 3, 2016 9:43 AM
>>> To: Rogovin, Kevin <kevin.rogovin at intel.com>; Myles C. Maxfield
>>> <mmaxfield at apple.com>
>>> Cc: webkit-dev at lists.webkit.org
>>> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>>>
>>> El jue, 03-11-2016 a las 07:35 +0000, Rogovin, Kevin escribió:
>>>> Hi,
>>>>
>>>> The main issue of making a Cairo backend to FastUIDraw is clipping.
>>>> Cairo tracks the clipping region in CPU and does things that are fine
>>>> for CPU-based rendering (i.e. span based rendering) but are
>>>> absolutely awful for GPU rendering (from my slides, one sees that GL
>>>> backed QPainter and Cairo do much worse than CPU backed). FastUIDraw
>>>> only supports clipIn and clipOut and pushes all the clipping work to
>>>> the GPU with almost no CPU work. It does NOT track the clipping
>>>> region at all. I can give more technical details how it works (and
>>>> those details are why FastUIDraw cannot be used a backend for Cairo).
>>>> For those interested in where the code is located for clipping in
>>>> FastUIDraw, it is located at src/fastuidraw/painter/painter.cpp,
>>>> methods clipInRect, clipOutPath and clipInPath. Their implementations
>>>> are very short and simple and are quite cheap on CPU.
>>>
>>> I see. Then I guess adding a new GraphicsContext for FastUIDraw is the easiest and best way to try this out in WebKit. Would it be possible to just add a new GraphicsContext implementation? or would you also need to change other parts of the graphics implementation or the GraphicsContext API itself?
>>>
>>>> Best Regards,
>>>> -Kevin
>>>>
>>>> -----Original Message-----
>>>> From: Carlos Garcia Campos [mailto:carlosgc at webkit.org]
>>>> Sent: Thursday, November 3, 2016 9:27 AM
>>>> To: Rogovin, Kevin <kevin.rogovin at intel.com>; Myles C. Maxfield <mmax
>>>> field at apple.com>
>>>> Cc: webkit-dev at lists.webkit.org
>>>> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>>>>
>>>> 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-specificati
>>>>> on
>>>>> -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/01
>>>>> or 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/Progra
>>>>> m/
>>>>> 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
>>> _______________________________________________
>>> 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
>
> --
> Regards,
> Konstantin
> _______________________________________________
> 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 <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/732e54b0/attachment.html>
More information about the webkit-dev
mailing list