I'm not sure it is directly helpful or not. And maybe, I think you already know that. But I remember that Cairo has some trace data to test the performance. And it includes the traces on WebKit. https://cgit.freedesktop.org/cairo-traces/
Best regards, Yusuke Suzuki On Thu, Nov 3, 2016 at 12:42 PM, Myles C. Maxfield <mmaxfi...@apple.com> wrote: > > 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>: > > 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/ > - Mozilla has a list of benchmarks https://wiki.mozilla.org/Benchmarks > - Canvas Performance 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 > <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 > <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 > <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 <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 > 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
