Hi all,

I have a couple of questions.

1. Is is a known limitation of gtk1 that you cannot change the form's color? I've tried to do this, but this (at design time) has no effect.

2. With gkt2, the form's color does change with what it was set to at design time but it I've noticed that there is a bit of transition. In other words, when the form is shown it takes on the default color and then changes so that you can see a splash of white before the color that was set at design time takes effect.

Note: I'm trying this in a Virtual Box image so there's not a lot of horsepower there for video. Does anyone else see this behavior?

Thanks,

Lee Jenkins wrote

1. Is is a known limitation of gtk1 that you cannot change the form's color? I've tried to do this, but this (at design time) has no effect.

One of many reasons why I started fpGUI. When we still used LCL & GTK1 (1.5-2 years ago), I was told it is not native behaviour and will not be fixed. Don't ask me what Linux native behaviour is, because every second Linux app behaves differently. :) A work around was to create some custom theme file, but that was not a solution for us.

I have no idea what's the state of LCL & GTK1 at the moment, regarding this issue. But from your comment, it seems nothing has changed.

2. With gkt2, the form's color does change with what it was set to at design

I can't comment on GTK2. 1.5 years ago, GTK2 was totally unusable.

Regards,
- Graeme -

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

Hmmm. That's a bit unfortunate. I get the idea of theming and centralizing the user feel, etc but that doesn't take into account task based applications.

I've noticed also that other things like MouseDown and MouseUp seem to act differently (kind of sluggish) in GTK1/2 or maybe its Gnome in general. That's a show stopper for me.

Lee Jenkins wrote

Hmmm. That's a bit unfortunate. I get the idea of theming and centralizing the user feel, etc but that doesn't take into account task based applications.

Exactly our issue as well. We have a GUI application designed for kids and need it colourful. We also have a admin GUI application designed for our franchises and needed custom (corporate) colours overall. We also use colour for input validation forms. Most of these worked when we ran under Windows, but not when it's run under Linux. Defeats the purpose of cross platform apps. Our custom drawn toolkit solves all these issues.

I've noticed also that other things like MouseDown and MouseUp seem to act differently (kind of sluggish) in GTK1/2 or maybe its Gnome in general. That's a show stopper for me.

Which components? LCL-GTK2 does feel slow compared to other non-LCL GTK2 based applications. GTK1 (I've got the Lazarus IDE compiled with in) seems okay.

Regards,
- Graeme -

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

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080523/3521cac4/attachment.pl

In view of all the double buffering, I'm not surprised that the GTK2 version works slow. Double buffering is evil (tm) unless you do moving graphics.

Michael.

This particular component is one that I wrote that simulates a button. It's derived from TShape and changes its border (pen) color and background (brush) color on mousedown and then changes it back on mouse up.

I've noticed it with plain TButton too however. For instance, I have a simple test app that loads a TListView with dummy data in a 50 count loop. Many times you will not see the TButton's down state, the code to load the dummy data will just run. You can get it to work if you are conscious of pressing down and then wait maybe 150-250 ms and then release. Most people don't do that though ;)

I think gtk2 looks much better as well.

I assumed that the initial flicker that I see is caused by the forms default color being painted before the LCL gets a chance to paint over it again. I assumed the default color is based on whatever theme is in effect for the current user.

I will, but I am thinking its something in gtk because even other none lazarus apps seem sluggish, just that lazarus gtk2 apps seem to add some sluggishness over top of that.

Michael Van Canneyt wrote

In view of all the double buffering, I'm not surprised that the GTK2 version works slow. Double buffering is evil (tm) unless you do moving graphics.

FYI double buffer is disabled for all controls in LCL-Gtk2. This is one of the reasons of the difference between pure gtk2 apps

Luiz

Strange, if I'm correct, Mattias said that double buffering is used in synedit ?

Michael.

This is a double buffer in the SynEdit side. TCustomControl and TForm have double buffer disabled in gtk2 interface.

Luiz

Great.

Then what is the cause of the perceived slowness of the IDE under GTK 2 ?

Michael.

Michael Van Canneyt wrote

Then what is the cause of the perceived slowness of the IDE under GTK 2 ?

The only thing slow in the IDE is the code editor. The problem is with cairo, which is used to draw the text.

Is it cairo that forces use of double buffering ?
I mean, drawing text should be a cheap operation, IMHO ?

(not trying to be difficult, just trying to understand...)

Michael.

Do you mean pango instead of cairo.

Luiz

No LCL does not uses Gtk2 widgets is buffered by
default. Qt is also double buffered AFAIK.

I mean, drawing text should be a cheap operation, IMHO ?

Yes. But pango goes beyond drawing text. It supports full unicode (even broken utf8 encoded strings), bidi, complex text layout, text formatting.

It is one of the main culprits of the difference between gtk1 and gtk2 performance. Note that Gtk2 uses cairo only after 2.8

Luiz

Luiz Americo Pereira Camara wrote

Do you mean pango instead of cairo.

Umm ... probably

2008/5/24 Luiz Americo Pereira Camara :

No LCL does not uses Gtk2 widgets is buffered by default. Qt is also double buffered AFAIK.

So if all toolkits you mentioned are double buffered by default (fpGUI and MSEgui included), why is LCL not? Yet LCL (GTK) seems the slowest of them all on a Linux system.

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

So if all toolkits you mentioned are double buffered by default (fpGUI and MSEgui included), why is LCL not? Yet LCL (GTK) seems the slowest of them all on a Linux system.

I don't know why double buffering was added in the discussion, it has nothing to do with the slowness of SynEdit under gtk2.

Double buffering is simply a necessity to avoid flickering, and SynEdit is double buffered, regardless of the widgetset. It is not a vilain nor a magical solution for lcl-gtk2.

Michael Van Canneyt wrote

I mean, drawing text should be a cheap operation, IMHO ?

Maybe, but the library we are using to draw text is terribly slow, regardless if it should or shouldn't be slow.

2008/5/25 Felipe Monteiro de Carvalho :

I'm not referring to SynEdit. I'm simply asking why all components in the LCL are not double buffered by default? Yet the underlying toolkits are by default. What does LCL developers know that the rest of us toolkit authors don't? ;-)

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

I'm not referring to SynEdit. I'm simply asking why all components in the LCL are not double buffered by default? Yet the underlying toolkits are by default. What does LCL developers know that the rest of us toolkit authors don't? ;-)

I think it's not by every widgetset. I think we don't disable anything when using Qt widgets. I don't know why this was disable in gtk2, probably some problem that this was causing in lcl-gtk2.