We actually mentioned fastuidraw while we were at the contributors meeting as a 
potential replacement for our Cairo rendering for PlayStation. When we got to a 
point with our port where we can start evaluating we'd be interested in taking 
a look. The only problem I had with the setup was a reliance on boost, but 
maybe there are ways around it.

From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Rogovin, Kevin
Sent: Wednesday, November 2, 2016 9:36 AM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] WebKit GPU rendering possibility


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/01org/fastuidraw. I 
gave a talk at the X Developers Conference this year which can be seen from 
https://www.x.org/wiki/Events/XDC2016/Program/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

Reply via email to