It also looks like Cairo has a suite of performance tests checked into their repository: http://events.linuxfoundation.org/sites/events/files/slides/cairo_perf.pdf <http://events.linuxfoundation.org/sites/events/files/slides/cairo_perf.pdf>
—Myles > On Nov 3, 2016, at 12:32 PM, S. Litherum <lithe...@gmail.com> wrote: > > Some quick Googling reveals these open-source benchmarks: > MotionMark http://browserbench.org/MotionMark > <http://browserbench.org/MotionMark> > CaskBench https://github.com/ezhangle/caskbench > <https://github.com/ezhangle/caskbench> > Skia project’s collection of benchmarks > https://skia.googlesource.com/skia/+/master/bench/ > <https://skia.googlesource.com/skia/+/master/bench/> > Cairo-demos https://openbenchmarking.org/test/pts/cairo-demos > <https://openbenchmarking.org/test/pts/cairo-demos> > > Please feel free to try others not on this list. > > Thanks, > Myles > >> On Nov 3, 2016, at 12:19 PM, Brent Fulgham <bfulg...@apple.com >> <mailto:bfulg...@apple.com>> wrote: >> >> I would suggest “http://browserbench.org/MotionMark >> <http://browserbench.org/MotionMark>”. :-) >> >> -Brent >> >>> On Nov 3, 2016, at 12:17 PM, Rogovin, Kevin <kevin.rogo...@intel.com >>> <mailto:kevin.rogo...@intel.com>> wrote: >>> >>> 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. >>> >>> -Kevin >>> >>> -----Original Message----- >>> From: mmaxfi...@apple.com <mailto:mmaxfi...@apple.com> >>> [mailto:mmaxfi...@apple.com <mailto:mmaxfi...@apple.com>] >>> Sent: Thursday, November 3, 2016 9:07 PM >>> To: Rogovin, Kevin <kevin.rogo...@intel.com >>> <mailto:kevin.rogo...@intel.com>> >>> Cc: Carlos Garcia Campos <carlo...@webkit.org >>> <mailto:carlo...@webkit.org>>; webkit-dev@lists.webkit.org >>> <mailto: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 >>>> <mailto: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 >>>> <mailto:carlo...@webkit.org>] >>>> Sent: Thursday, November 3, 2016 9:43 AM >>>> To: Rogovin, Kevin <kevin.rogo...@intel.com >>>> <mailto:kevin.rogo...@intel.com>>; Myles C. Maxfield >>>> <mmaxfi...@apple.com <mailto:mmaxfi...@apple.com>> >>>> Cc: webkit-dev@lists.webkit.org <mailto: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 >>>>> <mailto:carlo...@webkit.org>] >>>>> Sent: Thursday, November 3, 2016 9:27 AM >>>>> To: Rogovin, Kevin <kevin.rogo...@intel.com >>>>> <mailto:kevin.rogo...@intel.com>>; Myles C. Maxfield <mmax >>>>> fi...@apple.com <mailto:fi...@apple.com>> >>>>> Cc: webkit-dev@lists.webkit.org <mailto: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 >>>>>> <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/ <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 >>>>>> <mailto:mmaxfi...@apple.com>] >>>>>> Sent: Thursday, November 3, 2016 1:30 AM >>>>>> To: Rogovin, Kevin <kevin.rogo...@intel.com >>>>>> <mailto:kevin.rogo...@intel.com>> >>>>>> Cc: webkit-dev@lists.webkit.org <mailto: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 >>>>>> <https://01.org/linuxgraphics/documentation/hardware-specificati> >>>>>> on >>>>>> -prms >>>>>> >>>>>> On Nov 2, 2016, at 9:35 AM, Rogovin, Kevin <kevin.rogo...@intel.com >>>>>> <mailto: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 >>>>>> <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 >>>>>> <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 <mailto: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 <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 <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 <mailto: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
