Guys,
Please check out Krzysztof's work so far. Flat color, gradients, and now patterns are already rendered with cairo; clips and masks, filters are off.
lp:~tweenk/inkscape/gsoc-cairo
The most exciting is that in my testing, on flat color and gradient files it's now faster very noticeably, from 30% to twice as fast depending on file and resolution. It's with cairo 1.8.8, no GPU acceleration (which as far as I know is not usable until cairo 1.10 anyway).
Tried, and personally I saw no performance gains yet (I only tried a little drawing and opening one complex file). Otherwise though, very nice to see things rendering the same as my installed copy on that more complex file. :) This was with cairo 1.9.8 for the record. I am looking forward to following this branch.
Cheers, Josh
On Tue, 2010-06-22 at 20:50 -0300, bulia byak wrote:
Guys,
Please check out Krzysztof's work so far. Flat color, gradients, and now patterns are already rendered with cairo; clips and masks, filters are off.
lp:~tweenk/inkscape/gsoc-cairo
The most exciting is that in my testing, on flat color and gradient files it's now faster very noticeably, from 30% to twice as fast depending on file and resolution. It's with cairo 1.8.8, no GPU acceleration (which as far as I know is not usable until cairo 1.10 anyway).
Tried, and personally I saw no performance gains yet (I only tried a little drawing and opening one complex file).
Actually it's expectable result. sK1 uses Cairo renderer almost 4 years and when I hear "new Cairo becomes 2x faster" I'm expecting 10% total performance increasing, no more.
Nevertheless, it would be interesting to test Caro 1.9.x branch.
Regards,
Igor Novikov sK1 Project http://sk1project.org
The numbers below don't need much comment. Our PNG export uses the same code as rendering. "inkscape" is with cairo patch, i-or is the nonpatched build. With gradient.svg the difference is even bigger - try it yourself.
$ time inkscape share/examples/tiger.svgz --export-png=aaa.png --export-dpi=1200 DPI: 1200 Background RRGGBBAA: ffffff00 Area 0:0:594:1052.36 exported to 7920 x 14031 pixels (1200 dpi) Bitmap saved as: aaa.png
real 0m12.537s user 0m12.433s sys 0m0.052s
$ time i-or share/examples/tiger.svgz --export-png=aaa.png --export-dpi=1200 DPI: 1200 Background RRGGBBAA: ffffff00 Area 0:0:594:1052.36 exported to 7920 x 14031 pixels (1200 dpi) Bitmap saved as: aaa.png
real 0m17.511s user 0m17.409s sys 0m0.084s
Oops, sorry for misinformation - it appears PNG export is broken in the cairo build, so the comparison is not quite fair :)
Anyway, I do see significant speedup in interactive use in some places. For example open markers.svg and zoom into the wide horizontal narrow-striped path at bottom. Cairo redraws it at least twice as fast.
PNG surface benchmark is imprecise indicator. The most important results are benchmarks for Image and Xlib surfaces because they are used for interactive mode.
And of course heavy weight sample rendering test is desirable. Like following:
http://www.securesoft.ru/download/samples_cdr.zip
Regards,
Igor Novikov sK1 Project http://sk1project.org
On Wed, Jun 23, 2010 at 7:14 PM, bulia byak <buliabyak@...400...> wrote:
Oops, sorry for misinformation - it appears PNG export is broken in the cairo build, so the comparison is not quite fair :)
Anyway, I do see significant speedup in interactive use in some places. For example open markers.svg and zoom into the wide horizontal narrow-striped path at bottom. Cairo redraws it at least twice as fast.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Wed, Jun 23, 2010 at 4:20 PM, Igor Novikov <igor.e.novikov@...400...> wrote:
PNG surface benchmark is imprecise indicator. The most important results are benchmarks for Image and Xlib surfaces because they are used for interactive mode.
We don't use anything but Image surface (at least at the moment), both for screen and for export.
2010/6/23 bulia byak <buliabyak@...400...>:
On Wed, Jun 23, 2010 at 4:20 PM, Igor Novikov <igor.e.novikov@...400...> wrote:
PNG surface benchmark is imprecise indicator. The most important results are benchmarks for Image and Xlib surfaces because they are used for interactive mode.
We don't use anything but Image surface (at least at the moment), both for screen and for export.
Actually, in interactive mode, we draw directly on the Xlib surface provided by GTK. However, I might need to change this to accomodate filters. There are still some gains to be made, for example the Livarot polygons are still recomputed, though they aren't used for anything.
Regards, Krzysztof
Actually, in interactive mode, we draw directly on the Xlib surface provided by GTK.
This way is really slow. On first stage of sK1 "cairofication" we also used direct drawing on Xlib surface. But as I have noticed in my presentation on LGM 2007, the surface is slow, because it uses X11 protocol. So rendering scheme:
model -> cairo -> Xlib surface (i.e. XWin)
should be considered as:
X CLIENT X SERVER model ->cairo -> xlib -> | X11 | ->Xlib -> XWin
X11 and Xlib don't support RGBA graphics, so to render RGBA images (for example antialiased curves) Cairo reads from X Server either part or whole canvas window as RGB image, pasts RGBA drawing on X Client side and returns back this RGB result. And this procedure is repeated for each drawing command. Therefore such rendering is very slow.
To increase rendering performance we use intermediate Image surface. Image surface is allocated on X Client side, so rendering on this surface is a quite fast. We use RGB Image surface, because it's compartible with Xlib. This surface is the same as canvas by size and has white bg. Our rendering scheme is following:
model -> Image (RGB) model -> Image (RGB) .... model -> Image (RGB) model -> Image (RGB)
--- End of model rendering ---
Image (RGB) -> Xlib surface
So we have only one bitmap transfer through X11 protocol and this has allowed us greatly increasing rendering performance.
Nevertheless, cairo rendering is slow, so this thread was really interesting for me and I'm going to play with latest Cairo branch to test current improvements.
I hope that our small expirience could be helpful for Inkscape development.
Regards,
Igor Novikov sK1 Project http://sk1project.org
W dniu 24 czerwca 2010 03:39 użytkownik Igor Novikov <igor.e.novikov@...400...> napisał:
This way is really slow. On first stage of sK1 "cairofication" we also used direct drawing on Xlib surface. But as I have noticed in my presentation on LGM 2007, the surface is slow, because it uses X11 protocol. So rendering scheme:
model -> cairo -> Xlib surface (i.e. XWin)
should be considered as:
X CLIENT X SERVER model ->cairo -> xlib -> | X11 | ->Xlib -> XWin
The X11 protocol only needs to be used when the X server is remote. When the X server is local, the Xshm extension can be used, making X drawing at least as fast as the image surface. Additionally, the Xrender extension can be used to accelerate some compositing operations.
At the moment I changed to using an intermediate image surface, but the two approaches differ only in the initialization. At the end of my project I will benchmark them both and use the faster one.
Regards, Krzysztof
On Jun 27, 2010, at 4:39 PM, Krzysztof Kosiński wrote:
At the moment I changed to using an intermediate image surface, but the two approaches differ only in the initialization. At the end of my project I will benchmark them both and use the faster one.
Good.
Just please be sure not to sacrifice on the situation with the remote X server. It is a far more common scenario than one might think (and that is not counting how it is my default mode of operation).
W dniu 28 czerwca 2010 01:56 użytkownik Jon Cruz <jon@...18...> napisał:
Just please be sure not to sacrifice on the situation with the remote X server. It is a far more common scenario than one might think (and that is not counting how it is my default mode of operation).
In the remote X server scenario, the intermediate surface approach will be significantly faster.
Regards, Krzysztof
2010/6/23 Krzysztof Kosiński <tweenk.pl@...400...>:
2010/6/23 bulia byak <buliabyak@...400...>:
On Wed, Jun 23, 2010 at 4:20 PM, Igor Novikov <igor.e.novikov@...400...> wrote:
PNG surface benchmark is imprecise indicator. The most important results are benchmarks for Image and Xlib surfaces because they are used for interactive mode.
We don't use anything but Image surface (at least at the moment), both for screen and for export.
Actually, in interactive mode, we draw directly on the Xlib surface provided by GTK. However, I might need to change this to accomodate filters.
Yes, filters are another reason to avoid this, which is what I recommended when we discussed this (another being relative slowness). Let's keep, at least for now, the old approach: render everything to image surface, apply filters to it if needed, and then output bitmap via the GDK call.
participants (5)
-
bulia byak -
Igor Novikov -
Jon Cruz -
Joshua A. Andler -
Krzysztof Kosiński