Hi,

I'm not ranting, simply trying to find out if it's a local issue (system or software). Though, none of my other GTK2 applications have this problem, only Lazarus.

I got a svn update of Lazarus today and compiled with GTK2. I normally use GTK1. They IDE looks fine and pretty (anti-aliased fonts etc), but usably sucks.

* Flicking through the menus causes a lot of flicker!
* Typing in the IDE editor window, cause the current typed text to flicker and it looks like the text cursor jumps back and forward one character as I type.
* Compiling projects and looking at the Message window. Some serious flicker as the compiler output updates the window.

Some positives:
* The dialogs look better.
* Anti-aliased text makes a major difference.
* Text seems to fit the dialog better, much less text clipping than under GTK1.

Is there some debug code enabled for the GTK2 interface, that could explain the slow redrawing speed? It looks like double-buffering is totally disabled in LCL-GTK2.

Regards,
- Graeme -

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

It does not flicker here (gtk2/ubuntu). So, maybe you just use a difficult gtk2 theme.

The menus are completely drawn by gtk. If they flicker, then you should see flickering in other applications too.

But it is true, that the ExtTextOut function, which is used by SynEdit, under gtk2 is at least 5 times slower than under gtk1. It uses pango functions, which are great for full unicode support, but snail slow. Probably the font system must be changed to cairo.

Mattias

I use a fresh Mandriva Linux 2008 with KDE in a 3.2 GHz dual core Pentium 4.

I don't remember any problem with the menus. My biggest problem with the Gtk 2 IDE is exactly the flickering in the code editor that you mentined =/ Typing takes a very noticable time to show the characters on screen, which is very annoying. No other software suffers from that.

So no, it's not only with you the problem =)

The cairo guys, call the text functions of cairo the "toy" api and recommend using pangocairo.

All in all, since LCL is drawing in a drawable directly, does not makes sense using only the cairo text functions. Better would be use Xft.

Luiz

2008/4/25 Mattias Gaertner :

It does not flicker here (gtk2/ubuntu). So, maybe you just use a difficult gtk2 theme.

I'm using the Bluecurve theme under GTK2 with Ubuntu 7.10. Bluecurve is not a very graphics intesive theme, like some others.

The menus are completely drawn by gtk. If they flicker, then you should see flickering in other applications too.

Further investigation revealed the problem. It's only menus that show over the IDE Editor window, and it's actually the Editor windows that takes long to redraw, which causes it to look like flicker. Using the menus on the left (File, Edit etc...) which are not over the Editor window, displays quickly, like all other GTK2 apps.

But it is true, that the ExtTextOut function, which is used by SynEdit, under gtk2 is at least 5 times slower than under gtk1. It uses pango functions, which are great for full unicode support, but snail slow. Probably the font system must be changed to cairo.

OK, that would definitely explain the slowness I experience. Why don't you use Xft directly? fpGUI uses Xft and unicode support is perfect. That way you will get unicode support in the editor, should have faster redraws and might even give GTK1 widgetset a unicode (and truetype fonts enabled) Editor as well.

Regards,
- Graeme -

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

2008/4/26 Felipe Monteiro de Carvalho :

I use a fresh Mandriva Linux 2008 with KDE in a 3.2 GHz dual core Pentium 4.

Wow, that's a beefy machine! My work PC is a P4 2.4GHz (single core).

It's very annoying indeed. But I'm glad to know it's not only an issue on my system. :) Overall, I'm very impressed with how much the GTK2 interface has improved since the last time I tried it (a few months back). Excellent work guys!

Regards,
- Graeme -

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

Good. So the only speed problems are the TextOut functions.

AFAIK Cairo works on more gtk platforms than XFT, so Cairo can reduce IFDEFs and maintenance work.
I have to test, how much faster XFT is and how complicated Cairo is. A small gtk test application is needed for each system to test the font selection, font information and text drawing.

Mattias

Yes and no. See below.

I have to test, how much faster XFT is and how complicated Cairo is.

Cairo is not , as i said early, the text
rendering api provided with the cairo core is not suited for what LCL need.

Quote from cairo doc about cairo_show_text :

"The |cairo_show_text()|
<http://cairographics.org/manual/cairo-Text.html#cairo-show-text> function call is part of what the cairo designers call the "toy" text API. It is convenient for short demos and simple programs, but it is not expected to be adequate for serious text-using applications. See |cairo_show_glyphs()|
<http://cairographics.org/manual/cairo-Text.html#cairo-show-glyphs> for the "real" text display API in cairo"

Yes you can play with cairo_show_glyphs but you would to make all manually: clipping, multiline, bidi, underline.

What Behdad Esfahbod has to say about it:
http://article.gmane.org/gmane.comp.lib.cairo/12247 What Carl Worth has to say:
http://article.gmane.org/gmane.comp.lib.cairo/12607

Now the funniest part: the system font selection. Cairo provides another "toy" api for that:
http://cairographics.org/manual/cairo-Text.html#cairo-select-font-face It provides basic options. For integration with the system fonts you would need to deal with the font backends: win32, FreeType + FontConfig for linux, ATSUI/CGFont for MacOSX.
So you loose the "no ifdef" advantage.
Yes, you could abstract that in OOP fashion with a descendant for each OS. I already tried that but give up when i found that FreeType binding is incomplete and the FontConfig one does not is a lot of work. And not for kids. *
*Luiz

About slowness of synedit/gtk2: i noticed, in svn logs, you are trying to optimize synedit paint by using canvas.cliprect. This won't help much under gtk2 because cliprect is always = clientrect. Take a look into bug report 8871. I posted a patch and some notes.

Luiz

Is PaintRect/ClipRect providing any useful information under gtk2? I am using a custom control, and it seems to always repaint the entire screen, even if only a small part is needed (such as a disappearing hint window).

Colin

No.

I am using a custom control, and it seems to always repaint the entire screen, even if only a small part is needed (such as a disappearing hint window).

This is the current behavior. I provided a patch in bug report 8871 that you can try and see if your component works OK.
For my side, VirtualTreeView is OK.

Luiz

Le Apr 29, 2008 ? 4:37 AM, Luiz Americo Pereira Camara a ?crit :

Since a few revision, the IDE under Windows is realy slow and Lazarus takes 20% when your cursor is in the source editor. Is it related to this discussion ?

Le Apr 29, 2008 ? 11:04 AM, Damien Gerard a ?crit :

(actually not always the case but it is recent)

Is it related to this discussion ?

No. Is related to gtk2 only.

Luiz

Le Apr 29, 2008 ? 11:38 AM, Luiz Americo Pereira Camara a ?crit :

Actually it is not the source editor. The code explorer window was opened :)