Re: [webkit-dev] WebKit GPU rendering possibility

[Yusuke SUZUKI]

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 
wrote:

>
> On Nov 3, 2016, at 12:34 PM, Konstantin Tokarev  wrote:
>
>
>
> 03.11.2016, 22:18, "Rogovin, Kevin" :
>
> 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
> ]
> Sent: Thursday, November 3, 2016 9:07 PM
> To: Rogovin, Kevin 
> Cc: Carlos Garcia Campos ;
> 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 
> 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 ; Myles C. Maxfield
>  
>  Cc: webkit-dev@lists.webkit.org
>  Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>
>  El jue, 03-11-2016 a las 07:35 +, 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 

Re: [webkit-dev] WebKit GPU rendering possibility

[Myles C. Maxfield]

> On Nov 3, 2016, at 12:34 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 03.11.2016, 22:18, "Rogovin, Kevin"  >:
>> 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]
>> Sent: Thursday, November 3, 2016 9:07 PM
>> To: Rogovin, Kevin 
>> Cc: Carlos Garcia Campos ; 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  
>>> 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 ; Myles C. Maxfield
>>>  
>>>  Cc: webkit-dev@lists.webkit.org
>>>  Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>>> 
>>>  El jue, 03-11-2016 a las 07:35 +, 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 

Re: [webkit-dev] WebKit GPU rendering possibility

[S. Litherum]

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 


—Myles

> On Nov 3, 2016, at 12:32 PM, S. Litherum  wrote:
> 
> Some quick Googling reveals these open-source benchmarks:
> MotionMark http://browserbench.org/MotionMark 
> 
> CaskBench https://github.com/ezhangle/caskbench 
> 
> Skia project’s collection of benchmarks 
> https://skia.googlesource.com/skia/+/master/bench/ 
> 
> 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 > > wrote:
>> 
>> I would suggest “http://browserbench.org/MotionMark 
>> ”. :-)
>> 
>> -Brent
>> 
>>> On Nov 3, 2016, at 12:17 PM, Rogovin, Kevin >> > 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 ] 
>>> Sent: Thursday, November 3, 2016 9:07 PM
>>> To: Rogovin, Kevin >> >
>>> Cc: Carlos Garcia Campos >> >; 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 >>> > 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 >>> >; Myles C. Maxfield 
 mailto: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 +, 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 loc

Re: [webkit-dev] WebKit GPU rendering possibility

[Konstantin Tokarev]

03.11.2016, 22:18, "Rogovin, Kevin" :
> 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.

>
> -Kevin
>
> -Original Message-
> From: mmaxfi...@apple.com [mailto:mmaxfi...@apple.com]
> Sent: Thursday, November 3, 2016 9:07 PM
> To: Rogovin, Kevin 
> Cc: Carlos Garcia Campos ; 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  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 ; Myles C. Maxfield
>>  
>>  Cc: webkit-dev@lists.webkit.org
>>  Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>>
>>  El jue, 03-11-2016 a las 07:35 +, 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 ; Myles C. Maxfield >>  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 +, 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

Re: [webkit-dev] WebKit GPU rendering possibility

[S. Litherum]

Some quick Googling reveals these open-source benchmarks:
MotionMark http://browserbench.org/MotionMark 

CaskBench https://github.com/ezhangle/caskbench 

Skia project’s collection of benchmarks 
https://skia.googlesource.com/skia/+/master/bench/ 

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  wrote:
> 
> I would suggest “http://browserbench.org/MotionMark 
> ”. :-)
> 
> -Brent
> 
>> On Nov 3, 2016, at 12:17 PM, Rogovin, Kevin > > 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 ] 
>> Sent: Thursday, November 3, 2016 9:07 PM
>> To: Rogovin, Kevin mailto:kevin.rogo...@intel.com>>
>> Cc: Carlos Garcia Campos mailto: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 >> > 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 >> >; Myles C. Maxfield 
>>> mailto: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 +, 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 
>>

Re: [webkit-dev] WebKit GPU rendering possibility

[Brent Fulgham]

I would suggest “http://browserbench.org/MotionMark 
”. :-)

-Brent

> On Nov 3, 2016, at 12:17 PM, Rogovin, Kevin  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] 
> Sent: Thursday, November 3, 2016 9:07 PM
> To: Rogovin, Kevin 
> Cc: Carlos Garcia Campos ; 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  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 ; Myles C. Maxfield 
>> 
>> Cc: webkit-dev@lists.webkit.org
>> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>> 
>> El jue, 03-11-2016 a las 07:35 +, 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 ; Myles C. Maxfield >> 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 +, 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 r

Re: [webkit-dev] WebKit GPU rendering possibility

[Rogovin, Kevin]

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] 
Sent: Thursday, November 3, 2016 9:07 PM
To: Rogovin, Kevin 
Cc: Carlos Garcia Campos ; 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  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 ; Myles C. Maxfield 
> 
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
> 
> El jue, 03-11-2016 a las 07:35 +, 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 ; Myles C. Maxfield > 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 +, 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

Re: [webkit-dev] WebKit GPU rendering possibility

[Myles C. Maxfield]

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  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 ; Myles C. Maxfield 
> 
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
> 
> El jue, 03-11-2016 a las 07:35 +, 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 ; Myles C. Maxfield > 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 +, 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 a

Re: [webkit-dev] WebKit GPU rendering possibility

[Rogovin, Kevin]

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 ; Myles C. Maxfield 

Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] WebKit GPU rendering possibility

El jue, 03-11-2016 a las 07:35 +, 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 ; Myles C. Maxfield  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 +, 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 a

Re: [webkit-dev] WebKit GPU rendering possibility

[Carlos Garcia Campos]

El jue, 03-11-2016 a las 07:35 +, 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 ; Myles C. Maxfield  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 +, 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
> >

Re: [webkit-dev] WebKit GPU rendering possibility

[Rogovin, Kevin]

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.

Best Regards,
-Kevin

-Original Message-
From: Carlos Garcia Campos [mailto:carlo...@webkit.org] 
Sent: Thursday, November 3, 2016 9:27 AM
To: Rogovin, Kevin ; Myles C. Maxfield 

Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] WebKit GPU rendering possibility

El jue, 03-11-2016 a las 06:58 +, 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

Re: [webkit-dev] WebKit GPU rendering possibility

[Carlos Garcia Campos]

El jue, 03-11-2016 a las 06:58 +, 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