Hi,

I know this is a off-topic, but here are quite diverse users lurking around that could give some valuable feedback.

Luiz Americo recently create a custom fpGUI component and package so Cairo could be used in fpGUI based applications. I saw he did the same for LCL.

I read a bit on the Cairo website to see what it does. I don't really know Cairo. It seems to be another SDL or AggPas, though it seems pretty easy to use.

* Does anybody else know Cairo or used it before?

* What is your feeling about the library?

* Does it come standard with X11? I read some docs on the net (dated
2000) that Cairo was an idea for a new graphics subsystem in X Windows to take advantage of newer video cards emerging in the market. Did that idea materialize? Is Cairo now considered standard with X11 like Xft?

* How is it's support on Windows or Mac OS X?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Not from my head, just googled out stuff:

GTK+ <http://en.wikipedia.org/wiki/GTK%2B>, starting in 2005 with version 2.8, uses Cairo to render the majority of its widgets <http://en.wikipedia.org/wiki/Widget_%28computing%29>.

Trying to remove libcairo2 causes the removal of everything else, including libgtk2 etc. on Hardy Heron (64bit) so at least on linux, I'd say it's "part of the system" when considering gtk2 setups.

If the gtk 2.8 comment (from wikipedia) is true, then we should be safe to use it on unix platforms at least (we're supporting 2.6+ but I think going to 2.8+ as minimum is doable?)

Ales

Thanks for pointing me to wikipedia. I found the following page listed below. It's an informative page that helped explain Cairo to me. It's seems my comparison with SDL, AggPas etc was spot on. In summary, Cairo is a platform neutral API to 2D graphics.

http://en.wikipedia.org/wiki/Cairo_%28graphics%29

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

No. Cairo is one component of the gtk stack although it can be used independently of gtk. The only dependency is libpng AFAIK.

* How is it's support on Windows or Mac OS X?

Windows is marked as supported platform (in fact, most of my dev with cairo is done in windows). Starting with 1.6 Mac OSX/Quartz is marked as supported. As a side note, Firefox 3 uses cairo to render all stuff in all platforms (this is one of the reasons to the speedup in page loading).

Luiz

Additionally, there's an ongoing effort to port the graphics WebKit backend to cairo under windows to avoid the binary only graphic library used currently.

Another relevant aspect of cairo, is the ability to have the same output to different targets (screen, image, pdf, ps) using the same code. That's handy, e.g., to print preview screens.

Luiz

Graeme Geldenhuys wrote

* What is your feeling about the library?

It was found that cairo is the reason why lcl-gtk2 is so slow, and therefore, I don't like it very much =)

2008/5/17 Felipe Monteiro de Carvalho :

That is strange. The first complaint I here that it is slow. I ran the the Lazarus Sprite demo, ported to use LCL and Cairo. It ran at normal resolution and maximized (stretched drawing) and it was silky smooth. CPU usage was constant between 0.0-0.3% which is very good.

Anybody know of a comparisons / performance tests between Cairo and something like Agg/AggPas or SDL?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2008/5/17 Graeme Geldenhuys :

That is strange. The first complaint I here that it is slow. I ran

OK, I did some more Google'ing. It seems Cairo does have some performance issues, but I can't remember to which version of Cairo they used. What I did notice from all my searching is that it is really unfair to compare Qt vector graphics to anything else! Qt is simply miles ahead of anybody else in performance. See image.

http://chaos.troll.no/~zrusin/vectorframeworks.png http://zrusin.blogspot.com/2006/10/benchmarks.html

Oh well, I my small little test, Cairo performed well and looked good. Next I'll play with AggPas. :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Is that number of seconds to complete the test? :P

Micha

2008/5/17 Micha Nelissen :

Nope, frame per second if I remember correctly. What I do remember of that graph is the higher the number, the better the performance.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

What I did notice from all my searching is that it is really unfair to compare Qt vector graphics to anything else! Qt is simply miles ahead of anybody else in performance.

As it is the only graphics framework actually using your graphics card that is really no surprise.

Some facts:
- LCL-gtk2 applications are slower than gtk2 pure applications
- LCL does not use cairo directly to draw, it uses gdk
- Gdk is faster than cairo
- Gtk2 internally still uses gdk in most places

So assuming cairo is used a lot by gtk2 this could explain why Gtk2 is slower than Gtk1 but not that LCL-Gtk2 is slower than Gtk2.

Things to look when optimizing LCL-Gtk2:

- Pango (FontConfig is called a lot in LCL-Gtk2 applications)
- Double buffer is disabled

If the LCL devels agree in one week i can provide a complete separated Gtk2 interface so the changes to get LCL-Gtk2 faster can be done easily and without breaking gtk1

Luiz

Probably Qt is still faster than cairo but the gap maybe smaller.

The test was with an aged cairo version. Recently a lot of optimizations are being done in cairo by taking advantage of using mmx/sse.

There's also an GSoC project to improve the polygon rasterizer.

Unfortunately, the OpenGL backend is still experimental but there are plans to doing hardware accelerated. A quote from a Mozilla/cairo dev: "Yep, the plan is to move to hardware accelerated rendering using OpenGL and/or DirectX as appropriate. We probably wont? be using Glitz though, but will develop a different backend for OpenGL/DX as glitz is heavily unmaintained at the moment and there are some things we?d like to do differently. But work on that probably won?t start for another few months at least."

Under MACOSX, is already hardware accelerated since uses quartz as backend (http://blog.vlad1.com/2008/03/16/cairo-16-quartz-and-gecko/).

One of the reasons of Firefox 3 speed up
(http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9068118&intsrc=hm_list) is the use of cairo (http://blog.vlad1.com/2007/12/11/graphics-in-mozilla/)

Luiz

What did you measure? How much?

How do you know?

- Double buffer is disabled

What controls?

If the LCL devels agree in one week i can provide a complete separated Gtk2 interface so the changes to get LCL-Gtk2 faster can be done easily and without breaking gtk1

What do you mean with 'complete separated Gtk2 interface'?

Mattias

Mattias Gaertner wrote

> - LCL-gtk2 applications are slower than gtk2 pure applications What did you measure? How much?

I think that the great comparation is gedit vs SynEdit. gedit has a decent speed, while synedit (and thus lcl-gtk2) has noticable speed issues.

I think it was already determined that pango/cairo was the problem and that using gdk directly would solve our problems, wasn't it?

I think he means separating gtk2 from gtk1.

Is Luis in the dev mailling list? The issue of separating was already extensively discussed, and Mark didn't accept it, so we reached a compromise that only some parts can be split for now, and that we can't just split, but we need to first, or at the same time, improve the code.

The former mails talked about 2d vector graphics and polygon. gedit/synedit is about font. I just want to make sure, we are talking about the same things.

I think it was already determined that pango/cairo was the problem and that using gdk directly would solve our problems, wasn't it?

AFAIK there were only a few simple tests. And I presented some simple tests, that showed that the speed can vary a lot between the widgetsets on various machines.

Yes.

Mattias

LCL uses only gdk for draw.
For text, is still necessary to use pango (unlike LCL writes your own wrapper around FreeType/FontConfig, Win32 fonts, CGFont systems). Gdk text functions are deprecated/unmaintaned.

Yes. Separate physically the interface code.

In this case, if you change your mind i'm still here.

Luiz

See below.

How much?

There's no synthetic benchmark, just the gtk2 apps feels more responsive. Also LCL-Gtk2 applications flickers a lot unlike other gtk2 application in the same system

Some time ago, I profiled gtk2 pure/LCL-gtk2 applications with valgrind and found excess of FontConfig calls in LCL-gtk2.
Not sure how is today, after recent changes done in LCL trying to cache pango objects.

All?

It was already related in the mail list. Search for a thread "Lazarus v0.9.25 r13078M with gtk 2"

See another post

Luiz

Luiz Americo Pereira Camara wrote

For text, is still necessary to use pango (unlike LCL writes your own wrapper around FreeType/FontConfig, Win32 fonts, CGFont systems). Gdk text functions are deprecated/unmaintaned.

In the dev mailling list someone took a look at gedit code and said it uses gdk to draw it's text.

Whatever we are doing now in gtk2 text (which is used pango) is very wrong, because the performance is horrible. There must be a solution, or are you saying that there is no solution to improve the text drawing speed of gtk2 intf?

About general drawing speed I don't remember any problems with lcl-gtk2, so we shouldn't try to fix it.

In this case, if you change your mind i'm still here.

We would appreciate if you join the dev mailling list and work into splitting the events system, as proposed by Paul in the dev mailling list =)

Gedit uses GtkSourceView to show the text.
GtkSourceView is descendant of GtkTextView.
I looked into GtkSourceView and GtkTextView and did not found calls to gdk text functions (draw_text, draw_string). I've found pango calls. Gdk (and cairo) is used to draw graphics elements and to do buffering.

I'm saying that LCL can be switched to minimizes Pango overhead since it will not get in the gtk1 performance (bidi, full unicode, antialias has a price).

A tip: LCL uses PangoLayout that's a high level interface. It could use the low level functions.

About general drawing speed I don't remember any problems with lcl-gtk2, so we shouldn't try to fix it.

This is what i'm trying to say since the begin: cairo is used to do 2d draw and because LCL does not uses cairo, the performance problem is elsewhere.

Ok. Send me the info how to join.

Luiz

I took a quick look: pango is used to allocate fonts, but drawing text seems to be only done by gdk/gtk functions.

Whatever we are doing now in gtk2 text (which is used pango) is very wrong, because the performance is horrible. There must be a solution, or are you saying that there is no solution to improve the text drawing speed of gtk2 intf?

It depends.
Andrew compared pango vs gdk text drawing and the gdk was 5 times faster.
But pango automatically supports BIDI, paragraphs and many unicode issues.

Mattias

Attached is the test project I did. The text is assigned to the PangoLayout one time only; after *_layout_render is used.

Hope you like the particularly verbose way to render pascal code :)

Avg time for 5000 paint cycles ms:

Pango: 12920
GDK: 2785

Regards,

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtktext.lpi
Type: text/xml
Size: 1247 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080517/a1600bea/attachment-0001.xml -------------- next part --------------
An embedded and charset-unspecified text was scrubbed... Name: gtktext.lpr
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080517/a1600bea/attachment-0001.pl

Avg time for 5000 paint cycles: ms:

GDK: 8899
Pango: 28168

Ehm. The gdk version is *not* antialised on my screen. What must I change to get an antialiased font with the gdk version, so that I can compare them?

Mattias

... and there is no double buffering.
SynEdit uses double buffering, either its own or the one provided by the interface. In case of gtk1+2 it uses its own: It paints to a memory bitmap and then copies to the canvas.

Mattias