> On Nov 3, 2016, at 12:34 PM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 03.11.2016, 22:18, "Rogovin, Kevin" <kevin.rogo...@intel.com > <mailto:kevin.rogo...@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: mmaxfi...@apple.com [mailto:mmaxfi...@apple.com] >> Sent: Thursday, November 3, 2016 9:07 PM >> To: Rogovin, Kevin <kevin.rogo...@intel.com> >> Cc: Carlos Garcia Campos <carlo...@webkit.org>; webkit-dev@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.rogo...@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:carlo...@webkit.org] >>> Sent: Thursday, November 3, 2016 9:43 AM >>> To: Rogovin, Kevin <kevin.rogo...@intel.com>; Myles C. Maxfield >>> <mmaxfi...@apple.com> >>> Cc: webkit-dev@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:carlo...@webkit.org] >>>> Sent: Thursday, November 3, 2016 9:27 AM >>>> To: Rogovin, Kevin <kevin.rogo...@intel.com>; Myles C. Maxfield <mmax >>>> fi...@apple.com> >>>> Cc: webkit-dev@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:mmaxfi...@apple.com] >>>>> Sent: Thursday, November 3, 2016 1:30 AM >>>>> To: Rogovin, Kevin <kevin.rogo...@intel.com> >>>>> Cc: webkit-dev@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.rogo...@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@lists.webkit.org >>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>>> >>>>> _______________________________________________ >>>>> webkit-dev mailing list >>>>> webkit-dev@lists.webkit.org >>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > -- > Regards, > Konstantin > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> > https://lists.webkit.org/mailman/listinfo/webkit-dev > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
