I can't help notice that IDE 0.9.26 compiled for gtk2 crawls, I've not yet investigated the speed of gtk2 apps. Is this being slowed down by debugging code, and is there a compile-time option to disable this?

Somebody I know started experimenting with Lazarus for CE a few days ago but finds the performance unacceptable- vastly slower than C#. Is this likely to be caused by debugging code, and again can this be disabled- preferably without having to recompile the IDE?

I can't comment on CE, but gtk2 performance is very display driver related.

I've recently moved to freeBSD 64bit and was forced to use the OSS radeon driver, and my gtkperf result went from ~55s to ~5s.

Try gtkperf on your machine and see what you get. If any test takes more than few seconds, there's something wrong, either your theme, or your driver.

Gtk2 isn't the fastest kid on the block, but it's not that slow either, if the drivers perform. (you need to use 2D accel, like EXA)

Mark Morgan Lloyd wrote

Somebody I know started experimenting with Lazarus for CE a few days ago but finds the performance unacceptable- vastly slower than C#. Is this likely to be caused by debugging code, and again can this be disabled- preferably without having to recompile the IDE?

With CE I suppose you mean Windows CE?

Performance is a very generic term. Performance of what? Non-visual code? Graphics drawing?

I will suppose it is graphics drawing. No, I doubt that the debug information causes this. I have noticed the graphics speed do is much slower then in a desktop (I don't use .NET, so can't comment there), but I never researched to find the reason why.

Also, without a benchmark, your assertion is empty. Which Lazarus code is slower then which C# code? Are they really equivalent?

Ale? Katona wrote

I've recently moved to freeBSD 64bit and was forced to use the OSS radeon driver, and my gtkperf result went from ~55s to ~5s. Try gtkperf on your machine and see what you get. If any test takes more than few seconds, there's something wrong, either your theme, or your driver.

Holly crap!!! I have heard about 'gtkperf', but have never run it before. I did so now on my PC. P4 2.2GHz with 1GB ram and integrated ATI video card running Ubuntu 7.10 (32bit).

I couldn't believe the difference it makes when you switch between themes. The exact same PC, just different themes!! Here are my results:

28s - Custom (mixture of what I like)
21s - Bluecurve
26s - ClearLook
24s - Human
17s - Mist
43s - Crux

Wow, not all themes are created equal! :-)

Regards,
- Graeme -

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

Thanks, I'll investigate later and report back. gtkperf doesn't appear to be packaged for Debian yet, so I'll need to build from source making sure I can test both gtk 1 and 2 (does it actually support both)?

I've got the same poor- in fact apallingly unusable- gtk performance in the Lazarus IDE on multiple machines with both 0.9.26 and 0.9.24, with FPC 2.2.2 and 2.2.0, with Debian "Etch" and "Lenny", and- in cases where I've been able to test- both x86 and SPARC.

The common element is that in all cases I'm running X over the LAN, but while Lazarus is fairly snappy with gtk 1 if I recompile it for gtk 2, either from the command line or using its internal rebuild facility, performance plummets: I have to wait for about a minute before a component dropped onto a form appears.

I'll investigate but I'd add that I'm running KDE rather than Gnome. I'd not expect theming to get in the way in this case but I suppose that there is a possibility that gtk2 is looking for some sort of setup info that's missing and failing with no grace whatsoever.

Thinking about it, I'm pretty sure I see the same problem with Slackware 12.1 on x86 so it's not Debian-specific.

Mark Morgan Lloyd wrote

Thanks, I'll investigate later and report back. gtkperf doesn't appear to be packaged for Debian yet, so I'll need to build from source making sure I can test both gtk 1 and 2 (does it actually support both)?

'gtkperf' was also not in Ubuntu 7.10's repositories. I downloaded the .deb file from the sourceforge.net website. It installed without problems. I don't know if it supports GTK1 though.

either from the command line or using its internal rebuild facility, performance plummets: I have to wait for about a minute before a component dropped onto a form appears.

I have also noticed a drop in speed since I switched from GTK1 to GTK2, but mine is definitely not as slow as you describe. Thought I run my Lazarus locally, not over a LAN.

Regards,
- Graeme -

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

Sorry my english.

One time a go, i test this, the problem appear with "click" the mouse but when i use "space bar" to push a button the speed is normal!

2008/11/6 Mark Morgan Lloyd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20081106/36bba743/attachment.html

Graeme Geldenhuys wrote

'gtkperf' was also not in Ubuntu 7.10's repositories. I downloaded the .deb file from the sourceforge.net website. It installed without problems. I don't know if it supports GTK1 though.

It's still not in Debian "Lenny". I'll investigate later, but I think the problem is much more basic than a theme or similar.

My desktop screens are on a SPARC with everything else connected by X on VNC and I'm quite simply not changing that.

Here's what I'll do next: remove 2.2.3 and 0.9.26 from my desktop system since they're not reliable, reverting to 2.2.0 and 0.9.24 which have served me reasonably well. I'll do my best with my limited time and understanding to help pin down the 0.9.26+SPARC problems but if I can't then I'll quite simply stay on 0.9.24 on all platforms.

I already know that I can duplicate the gtk2 speed problem over X using Debian "Etch" which is what's installed on my desktop system, if I can't duplicate it on a local screen I think that helps pin the problem down.

and in another mail:

My desktop screens are on a SPARC with everything else connected by X on VNC and I'm quite simply not changing that.

Are you running remote by using a VNC server on your sparc end that using a vncviewer to access it remotely, or are you running X remote (sparc connecting to a remote X server)

The latter I can confirm as dog slow. Over a 1 Gb lan it takes minutes before the cursor moves one char in the editor. (Responses to mouseclicks on dialogs take the same time btw)
This resulted for me to continue laz development using a gtk1 IDE.

When using a VNCserver, it should work more smooth, since all is handled "locally" and only display changes are copied ove the LAN.

Marc

That must or be a GTK2 or Lazarus LCL issue then. I often connect to a remove server via 'ssh -X ....' and run apps remotely to display on my local screen. For example the fpGUI UI Designer and the new TextEdit component (SynEdit like component) doesn't have any issues. All user interactions (clicking, draging, typing) are instant, as if I were running them locally.

My plan was to develop remotely on the 64bit system, but display locally. That machine is very beefy compare to my desktop system. If Lazarus IDE can't run nicely over a remote connection, that will be a serious issue. :-(

Umm, I should really start working on LCL-fpGUI then. ;-) This might solve some issue for a few people.

Regards,
- Graeme -

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

Marc Weustink wrote

Are you running remote by using a VNC server on your sparc end that using a vncviewer to access it remotely, or are you running X remote (sparc connecting to a remote X server)

My comment was largely to illustrate the fact that I'm heavily oriented towards using a single keyboard and screen(s) rather than having to move between desk and whichever workbench a computer is on- even assuming it's got a keyboard etc. attached.

The only instance I'm routinely using VNC is to a Win-32 box I use for Delphi and as a client to the CIX conferencing system. I'm obviously connected to my Sun desktop system (Debian "Etch") directly, apart from that almost all other Debian and Slackware systems are accessed over X.

The remaining exception to the above is a SPARC system that Vincent was tinkering with- I think he's using X for that rather than VNC, but I'm not sure what combination of libraries he's been using.

The latter I can confirm as dog slow. Over a 1 Gb lan it takes minutes before the cursor moves one char in the editor. (Responses to mouseclicks on dialogs take the same time btw) This resulted for me to continue laz development using a gtk1 IDE.

That's much what I'm seeing, I similarly concluded that it would be better for the moment to continue with the IDE built for gtk1 but I assumed that there was debugging code in the system which at some point would be removed. If my assumption was wrong then I am troubled.

One thing does occur to me however. If I fire up a system based on Debian "Lenny", which I believe (somebody please correct me) is based on gtk 2, I observe that Gnome itself runs adequately over a networked X connection.

In other words, this problem is specific to Lazarus operating over a networked X connection, not to gtk 2 itself.

When using a VNCserver, it should work more smooth, since all is handled "locally" and only display changes are copied ove the LAN.

I'll investigate, but the number of systems set up here for VNC is limited unless it's needed for something special. In general I simply enable gdm with xdmcp and everything works fine.

If I get as far as being able to duplicate this problem in a standalone program what function should I use to get a millisecond (or better) time?

Graeme Geldenhuys wrote

Umm, I should really start working on LCL-fpGUI then. ;-) This might solve some issue for a few people.

I agree. The combination of 0.9.26+gtk1 crashing on SPARC and 0.9.26+gtk2 not crashing as soon but being unusable is a bit of a show-stopper for me.

:)

For low bandwith I would recommend to use a thightvnc server (in the early days I debugged lazarus this way in a sparc connecter through a isdn line)

Even for other gtk2 apps I see a slowdown (compared too running locally). But this all also depends heavely on your theme, your gpu and cpu power

In other words, this problem is specific to Lazarus operating over a networked X connection, not to gtk 2 itself.

I plan for .28 to find a way of reducing the amount of traffic between a LCL app and the X server.

???

Marc

If I get as far as being able to duplicate this problem in a standalone program what function should I use to get a millisecond (or better) time?

If I understand you correctly you need a high resolution timer? I recommend EpikTimer: http://wiki.lazarus.freepascal.org/EpikTimer

hih

Lord Satan wrote

If I understand you correctly you need a high resolution timer? I recommend EpikTimer: http://wiki.lazarus.freepascal.org/EpikTimer

Thanks, noted :-)

Well, something rather better than a seconds count, anyway :-)

This is on behalf of Andy Lawrie who is having problems connecting to the if I've done anything that screws the
formatting.

It was myself who experienced the speed problems. I tried to post them 4 or 5 times but the mailing list rejects my emails - I will try this once more.

As a test project I have been porting a WinCE (ARM) application I first wrote using C#. It's for PocketPC.

The C# version was compact but sluggish in operation, so I rewrote it in old fashioned vanilla C, directly to the WinCE API. This also produced a compact executable, and the execution speed was excellent. The downside is that development is painfully longwinded. While the C version of the app works just fine, I will at some point want to extend it, and Lazarus looks to be a far better development environment. And indeed, it is. I've been very impressed with it.

Most development was using the emulator, but when I copied it over to the PDA for the first time I was shocked by the performance. It's about 10 times slower than the C# version, which already was too slow. I knew the executables were going to be large, and accept that as a penalty for the very much easier development. But I hadn't considered that execution speed might be an issue.

All it is doing is drawing some standard edit boxes and buttons on the screen. The PDA I tried it on is an XDA Stellar.

Optimisation is on Level 1 and there are no checks enabled.

Is it possible I have just got some settings wrong somewhere, or is this speed to be expected?

pp Rgds, Andy

There appears to be far less difference in performance between a networked and local X session when 0.9.24/2.2.0 is used.

I've now got an Ethereal/Wireshark monitor running and can see around ten messages per second to a remote 0.9.24 gtk2 IDE. I might be wrong here and there might be cases where traffic increases, but so far I see nothing out of the ordinary.

I'll continue tinkering with this in case I can spot anything obvious. I may be some time...

Mark Morgan Lloyd wrote

Most development was using the emulator, but when I copied it over to the PDA for the first time I was shocked by the performance.

So the performance was good using the emulator?

All it is doing is drawing some standard edit boxes and buttons on the screen. The PDA I tried it on is an XDA Stellar.

Well, I can't think of why this kinds of things would be slow. They shouldn't, just simple as that.

Maybe your device has very little memory, and the executable fills it. Did you strip before moving the executable to the PDA?

The typical executable size without debug information is 1.5 MB

Is it possible I have just got some settings wrong somewhere, or is this speed to be expected?

No, it's not expected for such simple applications. Also considering this is the first report of such kind.

2008/11/7 Felipe Monteiro de Carvalho :

i agree. i have never seen this sluggishness myself, but it might be related to a certain widget or part of code. we won't be able to tell without further information or an isolated testcase.

henry

Felipe Monteiro de Carvalho wrote

Maybe your device has very little memory, and the executable fills it. Did you strip before moving the executable to the PDA?

Just in case Andy isn't familiar with this, how's it done on CE?

2008/11/7 Mark Morgan Lloyd :

compile with -Xs or manually run arm-wince-strip --strip-unneeded on the exe.

henry

2008/11/7 Henry Vermaak :

in lazarus there is "Strip Symbols From Executable (-Xs)" in the linker tab under compiler options.

henry

Henry Vermaak wrote

compile with -Xs or manually run arm-wince-strip --strip-unneeded on the exe.

I don't know if it's any different, but I usually do: arm-wince-strip --strip-all myfile.exe

Please, sorry.
I omit the fact that i talk about in LTSp Client machine.

2008/11/6 Osvaldo Filho

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20081107/efd2d9cc/attachment-0001.html

Thanks both. I've dropped Andy a note reminding him to check the ML.

Mark Morgan Lloyd wrote

There appears to be far less difference in performance between a networked and local X session when 0.9.24/2.2.0 is used.

0.9.27 (snapshot of a couple of weeks ago) compiled natively on an ARM (Debian "Etch" on an NSLU2 "slug") with gtk2 runs at full speed. However I note in this case that the window manager is FluxBox rather than KDE which I was using on other systems.

I need to try some methodical tests in case I'm overlooking something.

This from Andy:

The machine isn't short of RAM - it has 128Mb and I've closed down all all other programs.

But the .exe was 9.81Mb, not 1.5Mb!

Stripping, i.e. compiling with -Xs, made no difference. But, now knowing it should be smaller, I then played with all the compiler options and the one that did make a difference in the size was removing the default "display line numbers in run time error backtrace". With this unchecked the size came down to 1.615Mb.

Stripping, setting unit style "smart linkable" and "link smart" are all now set but made no difference.

I then copied the application over to the PDA again. The program load time (i.e. from tapping the icon to the start of drawing the window) was much better, but disappointingly the execution speed was not observably different, i.e. it still took a second to draw the window.

You should disable the (-gl) in debugging to have symbols stripped from exe.

Henrique.

_________________________________________________________________ Conhe?a o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20081108/7b1e35b9/attachment-0001.html

Lord Satan wrote

If I understand you correctly you need a high resolution timer? I recommend EpikTimer: http://wiki.lazarus.freepascal.org/EpikTimer

Thanks, very useful. Basic operation OK on ARM and SPARC as well as x86, Debian in all cases.

Mark Morgan Lloyd wrote

I need to try some methodical tests in case I'm overlooking something.

I've now got a minimal test project for this which does appear to show that the major problem is when gtk2 is run to a remote screen. Any difference between 0.9.24, 0.9.26 and 0.9.27 (as of a couple of weeks ago) is insignificant.

I particularly note that in most if not all remote gtk2 cases there's a significant delay between the form appearing and it being prepared to honour a mouse click, using a LAN monitor I do not see any significant traffic during this time. It might be that this freeze happens after any form change and that is what's screwing the IDE.

I'm not able to run some combinations of hardware and software on account of physical inaccessibility or a display manager not liking the available video adapter. Machines tend to be old but adequate :-)

Times below are in seconds required to change a panel's colour 1,000 times.

x86 800MHz laptop Debian "Lenny" 0.9.24/2.2.0
local
gtk 3.5
gtk2 12.4
remote
gtk 9.5
gtk2 60.3

x86 800MHz laptop Debian "Lenny" 0.9.26/2.2.2
local
gtk 3.7
gtk2 13.7
remote
gtk 10.0
gtk2 60.4

x86 300MHz SMP Slackware 12.1 0.9.26/2.2.2
local
gtk -----
gtk2 59.2
remote
gtk -----
gtk2 71.4

x86 300MHz SMP Debian "Lenny" 0.9.26/2.2.2
local
gtk -----
gtk2 -----
remote
gtk 10.0
gtk2 61.1

SPARC 400MHz SMP Debian "Etch" 0.9.24/2.2.0
local
gtk 2.1
gtk2 15.1
remote
gtk 9.5
gtk2 37.1

ARM 266MHz NSLU2 Debian "Etch" 0.9.27/2.2.2
local
gtk -----
gtk2 -----
remote
gtk 13.3
gtk2 163.3

x86 800MHz SMP Debian "Sarge" 0.9.24/2.2.0
local
gtk -----
gtk2 -----
remote
gtk 8.5
gtk2 30.1

Code is obviously available to anybody who's interested.

Wow, even local GTK2 is *way* slower than GTK1. So I really wasn't imagining it when I switch Lazarus IDE to GTK2.

I was curious to see what it does on my system. So I created a test based on what you said. I used GTK1, GTK2 and fpGUI toolkit. In all three tests all component where the exact same size and contained the exact same text. Here are my results from the following code:

-----------------------------------------------
procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
  s: TDateTime;
  e: TDateTime;
begin
  s := Now;
  for i := 1 to 1000 do
  begin
    if (i mod 2) = 0 then
      Panel1.Color := clRed
    else
      Panel1.Color := clBlue;
    Application.ProcessMessages;
  end;
  e := Now - s;
  writeln('Duration: ' + FormatDateTime('nn:ss.zz', e));
end;
-----------------------------------------------

Clearly GTK2 is as speedy as a snail !!! :-(

graemeg at graemeg-laptop:speed$ ./project1_gtk1
Duration: 00:00.229
Duration: 00:00.219
Duration: 00:00.231
Duration: 00:00.238
Duration: 00:00.306
graemeg at graemeg-laptop:speed$ ./project1_gtk2
Duration: 00:01.127
Duration: 00:01.065
Duration: 00:01.158
Duration: 00:01.055
Duration: 00:01.119
graemeg at graemeg-laptop:speed$ ./project1_fpgui
Duration: 00:00.275
Duration: 00:00.275
Duration: 00:00.274
Duration: 00:00.276
Duration: 00:00.276

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

Wow, even local GTK2 is *way* slower than GTK1. So I really wasn't imagining it when I switch Lazarus IDE to GTK2.

We are aware of that. But gtk1 has a lot of other problems too, so it isn't exactly a good choice. Just comparing speed may give a false impression that gtk1 is a good choice.

Clearly GTK2 is as speedy as a snail !!! :-(

On your system this may be true. I must admit that it was a while ago when I compared gtk and gtk2 performance, but on my system gtk2 was actually faster than gtk. Is my assumption correct, that you are running a 32bit system?

Graeme Geldenhuys wrote

Wow, even local GTK2 is *way* slower than GTK1. So I really wasn't imagining it when I switch Lazarus IDE to GTK2.

I think there's two things: the reduction in speed for every operation (e.g. changing a colour and redrawing) and the Big Freeze. In my opinion the freeze is by far the more important since at present the IDE is virtually unusable with gtk2 from a remote screen.

I've put in quite a lot of time over the last few days reverting to 0.9.24 on some of the development systems, partly so I could do these tests but also to get back to having a working compiler for SPARC. I really do need to get on with some other things, like work.

Having said that I want to try to get 0.9.27 onto my remaining available SPARC system, I'm very worried at the prospect of being marooned with gtk1 on 0.9.24 while the rest of the World moves on.

However I think I could also usefully take another look at that startup delay, get definite confirmation that it's not a LAN throughput issue and see whether I can find any other cases where it happens.

2008/11/10 Felipe Monteiro de Carvalho :

it's a bad choice, imho, since it's virtually obsolete on the desktop. there is a use for a light weight widget set for embedded systems, though.

lazarus gtk2 feels quite snappy on my crappy old laptop, so i'm not complaining.

henry

Please run "gtkperf" program on your end and give results (run it locally).

If you don't have it in packages, just get libgtk2-dev and compile from sources (./configure && make && make install [as root]).

If you get more than ~10 seconds, something is wrong with your setup (driver/X/theme). I get ~5s here with the OSS driver and EXA. Gtk2 flies quite fast.

2008/11/10 Graeme Geldenhuys

Here's my result, for your comparison (AMD Turion 64bit 1xcore, 2gb RAM, OSS Ati driver (no 3D) with EXA on ATI Mobility Radeon X1600:

GtkPerf 0.40 - Starting testing: Mon Nov 10 23:23:01 2008

GtkEntry - time: 0,03
GtkComboBox - time: 0,63
GtkComboBoxEntry - time: 0,54
GtkSpinButton - time: 0,07
GtkProgressBar - time: 0,05
GtkToggleButton - time: 0,19
GtkCheckButton - time: 0,23
GtkRadioButton - time: 0,31
GtkTextView - Add text - time: 0,66
GtkTextView - Scroll - time: 0,23
GtkDrawingArea - Lines - time: 0,46
GtkDrawingArea - Circles - time: 0,44
GtkDrawingArea - Text - time: 1,17
GtkDrawingArea - Pixbufs - time: 0,07
---
Total time: 5,08

2008/11/10 Ales Katona

Mark Morgan Lloyd wrote

Having said that I want to try to get 0.9.27 onto my remaining available SPARC system, I'm very worried at the prospect of being marooned with gtk1 on 0.9.24 while the rest of the World moves on

Did you tried to compile/use 0.9.27 with gtk1? It still possible to do
that. No need to switch to older versions of Lazarus/fpc.

Luiz

Lord Satan wrote

On your system this may be true. I must admit that it was a while ago when I compared gtk and gtk2 performance, but on my system gtk2 was actually faster than gtk.

Do you think your tests predated 0.9.24? I'd rather not go back any earlier unless the results were likely to be some use to somebody. As it is I'm not trying to criticise, but rather to exercise the code in a way that otherwise appears neglected.

Is my assumption correct, that you are running a 32bit system?

Mine certainly were.

2008/11/11 Ales Katona :

Here is the results I got a few days ago on my wok PC. My laptop is a bit faster than than - I'll run it shortly and post the results... I'm running the Clearlooks theme in my laptop.

-------------------[ Work PC ]----------------
I did so now on my PC. P4 2.2GHz with 1GB ram and integrated ATI video card running Ubuntu 7.10 (32bit).

I couldn't believe the difference it makes when you switch between themes. The exact same PC, just different themes!! Here are my results:

28s - Custom (mixture of what I like)
21s - Bluecurve
26s - ClearLook
24s - Human
17s - Mist
43s - Crux

Wow, not all themes are created equal! :-)
-------------------[ end ]----------------

Regards,
- Graeme -

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

And my laptop is a P4 3GHz with 1GB ram and ATI Radeon 9700 video card running Ubuntu 7.10 (32bit). Clearlooks theme.

-----------------------------------
graemeg at graemeg-laptop:~$ gtkperf
GtkPerf 0.40 - Starting testing: Tue Nov 11 08:51:36 2008

GtkEntry - time: 0.07
GtkComboBox - time: 3.70
GtkComboBoxEntry - time: 2.82
GtkSpinButton - time: 0.49
GtkProgressBar - time: 0.55
GtkToggleButton - time: 0.92
GtkCheckButton - time: 1.38
GtkRadioButton - time: 1.60
GtkTextView - Add text - time: 1.32
GtkTextView - Scroll - time: 0.61
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.54
GtkDrawingArea - Text - time: 5.29
GtkDrawingArea - Pixbufs - time: 0.42
---
Total time: 19.98
-----------------------------------

Things like GLGears and the Flurry screensaver is silky smooth on my laptop. It's much better than my work PC, but it's not near your 5 seconds!

Regards,
- Graeme -

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

En/na Mark Morgan Lloyd ha escrit:

I have an application made with 0.9.26/gtk2 that is routinely[*] run in remote through an ssh tunnel (the X server is either linux or windows xming).
While it's somewhat slower that running it locally (and by locally I mean through vnc, since the machine is headless, so that may mask some of the slowness), the difference doesn't seem as dramatic and the app is perfectly useable.
The machine where the application is running is a celeron M1.3GHz with 256M of ram, the os is mandriva 2007.1, kde desktop. I didn't try to run lazarus itself in remote though, but the performance of lazarus/gtk2 on my ageing laptop is very good. In fact, even when I was targeting gtk1 due to a memory leak in gtk2 (now solved), I've been using the ide compiled with gtk2 long before 0.9.26.

[*]actually the app is just to configure the machine, so it's not run everyday, but when it is used it works fine.

Bye

I'm not saying that gtk1 is a good choice, but with the performance of the gtk2 IDE to a remote screen it is, regrettably, an inevitable choice.

If a gtk2 program takes 13 seconds to run on a local screen against 3 for gtk1, well basically who cares? CPU power is cheap and users have to go with the flow- in just the same way that sooner or later they will have to abandon KDE3 in favour of KDE4 even if the user interface is unfamiliar and some facilities have been dropped. If a program is slow on a remote screen then users will just have to abandon that way of working- and while we're at it shouldn't we just recognise that X is obsolete and go straight to the hardware?

Look, I'm sorry but as long as both gtk1 and gtk2 are supported as standard- and particularly while gtk2 is marked "Beta" in 0.9.26 which I believe is the promoted stable release- it's just not feasible to brush UI and performance issues under the carpet. The fact is that users and developers won't change their hardware and way of working on a whim, they don't even do that without a lot of kicking and screaming when the whim comes from Microsoft.

I'd also suggest that saying that the machines Graeme or myself are running must be badly set up is not a valid defence. I can't speak for Graeme but in my case they're pretty much off-the-shelf Debian or Slackware systems, I don't fiddle with graphics setup lightly since I had to do far too much of that sort of thing 15 years ago when Linux was rather less mature than it is these days.

We've already probably lost Andy who found that CE performance was unacceptable, and I don't think he was particularly impressed by his initial problems with the documentation. What's more I'm in a position where I find myself wondering whether I should start looking at C# or possibly Embarcadero's current offering and quite simply tell our customers that there's no viable alternative to MS products.

If we can't find a way to sort out these two issues- documentation and performance/compatibility- we won't make any friends, no matter how good the IDE and language.

I got to the point of being able to compile 0.9.26 with gtk1 but it would bomb as soon as started, there might be residual problems in the underlying FPC 2.2.3. I think Vincent looked at it a bit on one of my machines but had other pressures. I want to try to find time to look at 0.9.27, but I don't know how quickly I'll manage it, reverting to reliable 0.9.24 then producing the timing figures has been a lot of work.

The problem is that gtk1 /is/ obsolescent. I maintain that it can't be considered deprecated until Debian "Lenny" is stable which won't be for at least a few more months, and it certainly can't be tagged as obsolete by Lazarus for as long as our stable release uses it as the default: maybe this time next year.

Sooner or later it won't be possible to insert gtk1 into a standard distro and there will be some reason why it's no longer possible to apply kernel patches and security updates- my guess would be because of some change in the way udev and related subsystems work. I've already found myself in that position with my SS1000Es which won't run anything later than Linux 2.2 (i.e. Debian "Woody") reliably, I've never found an FPC version that will run on them.

So I obviously can't conclude anything until I put more time into 0.9.26/27 on SPARC. I'd very much like to get it running reliably, apart from anything else that would give me more incentive to carry on using Delphi and Lazarus and hopefully to be able to put something useful back into the project. I'm keenly aware that if I looked at alternatives such as .NET/Mono I'd probably find that support for fading architectures would be far worse.

You're probably using closed-source nvidia or ati drivers?

The ATI ones suck bigtime when it comes to 2d performance, for me it goes to 50s on the circles test (others go fine).

Or perhaps, if you're using intel drivers or OSS versions ("readon", not sure about nvidia ones) try adding "Option" "AccelMethod" "EXA" to your device section in xorg.conf (WARNING: requires late X/drm, OR update your libdrm and drm kernel module from sources).

Works like a charm and shows pretty much that:
1. The closed source drivers have some bug (the circles speed here isn't normal)
2. There's 2D accel available but mostly unused
3. Gtk2 heavily relies on acceleration and good drivers regardless of LCL

By all means whatever works for you best. We're not offering solutions to keep "customers" here :)

If you don't like it there are basically 2 ways to go: go elsewhere, or help make it better. Your choice.

Mark Morgan Lloyd wrote

I'd also suggest that saying that the machines Graeme or myself are running must be badly set up is not a valid defence. I can't speak for Graeme but in my case they're pretty much off-the-shelf Debian or

I don't fiddle with graphics much. As long as I get the correct resolution for my LCD or Laptop screen and my "flurry" screensaver runs smoothly, I'm a happy man. :-) My OS is a stock standard Ubuntu 7.10 (32 bit) and the occasional apt security updates.

If we can't find a way to sort out these two issues- documentation and performance/compatibility- we won't make any friends, no matter how good the IDE and language.

Just curious... Could you compile the fpGUI UI Designer and run that remotely? Alternatively, I can email you a binary if you don't want to go through the compile process. If I run any fpGUI based apps remotely, I have no speed issues.

Also, I'm trying to complete the last few components for fpGUI so next year I can actively start the LCL-fpGUI widgetset integration.

Regards,
- Graeme -

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

Luca Olivetti wrote

I have an application made with 0.9.26/gtk2 that is routinely[*] run in remote through an ssh tunnel (the X server is either linux or windows xming).

That does of course raise the interesting point that part of the remote performance issue could be an X server issue. Fortunately I've got XMing on another laptop, so selecting one of the more "complete" sets of tests:

remote (XMing)
gtk 5.1
gtk2 199.9

remote (XMing)
gtk 5.0
gtk2 199.9

In the case of the gtk2 test I also time a 6 second "Big Freeze" between the form appearing and being usable.

I admit to being very surprised here by gtk1 being faster but gtk2 being so much slower. However this isn't a particularly recent copy of XMing- the machine is used for mundane but important jobs like setting up the PABX and it doesn't get fiddled with.

Graeme Geldenhuys wrote

I don't fiddle with graphics much. As long as I get the correct resolution for my LCD or Laptop screen and my "flurry" screensaver runs smoothly, I'm a happy man. :-) My OS is a stock standard Ubuntu 7.10 (32 bit) and the occasional apt security updates.

In the specific case of the laptop that I was able to use for the most complete set of tests that is a very clean system- it's had repeated ab-initio Debian "Lennys" installed onto it and it's not even got significant development files- the test programs were moved over as binaries.

Just curious... Could you compile the fpGUI UI Designer and run that remotely? Alternatively, I can email you a binary if you don't want to go through the compile process. If I run any fpGUI based apps remotely, I have no speed issues.

I'm fairly happy compiling from scratch- what sources do I need, what (Debian) development packages am I likely to require, is this from GUI or from command line and in either case what special instructions?

Ale? Katona wrote

You're probably using closed-source nvidia or ati drivers?

No, I am using nothing other than what come with the standard Debian or Slackware distros with the xorg.conf file as installed.

Some more competition: ;-)

Suse 11 32bit, AMD Athlon XP3000+ 2.15GHz, ATI Radeon 9200SE

gtkperf:

GtkEntry - time: 0.08
GtkComboBox - time: 2.40
GtkComboBoxEntry - time: 2.07
GtkSpinButton - time: 0.40
GtkProgressBar - time: 0.36
GtkToggleButton - time: 0.72
GtkCheckButton - time: 0.64
GtkRadioButton - time: 0.73
GtkTextView - Add text - time: 0.90
GtkTextView - Scroll - time: 0.75
GtkDrawingArea - Lines - time: 0.47
GtkDrawingArea - Circles - time: 0.67
GtkDrawingArea - Text - time: 1.19
GtkDrawingArea - Pixbufs - time: 0.56
---
Total time: 11.95

Lazarus GTK1
Duration: 00:00.435
Duration: 00:00.462
Duration: 00:00.461
Duration: 00:00.464
Duration: 00:00.462
Duration: 00:00.469

Lazarus GTK2
Duration: 00:04.269
Duration: 00:04.264
Duration: 00:04.277
Duration: 00:04.280
Duration: 00:04.290
Duration: 00:04.295

MSEgui button with caption, compiled with -B -O3
Duration: 00:00.214
Duration: 00:00.214
Duration: 00:00.213
Duration: 00:00.212
Duration: 00:00.215
Duration: 00:00.213

Lazarus code:
var
  i: integer;
  s: TDateTime;
  e: TDateTime;
begin
  s := Now;
  for i := 1 to 1000 do
  begin
    if (i mod 2) = 0 then
      Panel1.Color := clRed
    else
     Panel1.Color := clBlue;
    Application.ProcessMessages;
  end;
  e := Now - s;
  writeln('Duration: ' + FormatDateTime('nn:ss.zz', e));
end;
MSEgui code:
var
  i: integer;
  s: TDateTime;
  e: TDateTime;
begin
  s := Now;
  for i := 1 to 1000 do
  begin
    if (i mod 2) = 0 then
      tbutton1.Color := cl_Red
    else
     tbutton1.Color := cl_Blue;
    update;
  end;
  e := Now - s;
  writeln('Duration: ' + FormatDateTime('nn:ss.zz', e));
end;

MSEgui and fpGUI are double buffered (Graeme, please correct me if I am wrong with fpGUI).

Martin

I'm glad there was a smiley in that message :-)

Ale? Katona wrote

If you don't like it there are basically 2 ways to go: go elsewhere, or help make it better. Your choice.

This largely started because something wasn't working in gtk1, and I was told to use gtk2. Then I found out that gtk2 was only marginally usable.

Take the fact that I'm prepared to put in time trying to quantify the problem, and take the fact that the people I work for and with are prepared to tolerate that expenditure of time, as a commitment.

En/na Mark Morgan Lloyd ha escrit:

I didn't do any measurement, simply because I didn't notice any big problem with performance, and I saw no noticeable difference between the linux x server and xming.
In both cases the connection is tunneled through ssh without compression, which, if anything, should make things even worse.

In the case of the gtk2 test I also time a 6 second "Big Freeze" between the form appearing and being usable.

No such freeze here (wait, I saw something similar once on the production machine in another project, but it was gtk1 that was busy substituting fonts or something, fixed with a .gtkrc, never saw it with gtk2)

I admit to being very surprised here by gtk1 being faster but gtk2 being so much slower. However this isn't a particularly recent copy of XMing- the machine is used for mundane but important jobs like setting up the PABX and it doesn't get fiddled with.

The version of xming I used is 6.9.0.23 but I doubt it makes a difference. I'm surprised with your results, I didn't tune anything, everything was configured automatically by mandriva. I'll see if I can try to run lazarus itself remotely, just to check if my experience matches yours.

Bye

En/na Luca Olivetti ha escrit:

I'm surprised with your results, I didn't tune anything, everything was configured automatically by mandriva. I'll see if I can try to run lazarus itself remotely, just to check if my experience matches yours.

I just tried and lazarus itself is unusable this way. The display of things is quite speedy, but reaction to mouse clicks lags 3 or more seconds.

Bye

Luca Olivetti wrote

No such freeze here (wait, I saw something similar once on the production machine in another project, but it was gtk1 that was busy substituting fonts or something, fixed with a .gtkrc, never saw it with gtk2)

I'll try to add a test for this to my program, but I've seen it repeatedly.

fpGUI, current trunk, button with caption, compiled with -B -O3 Duration: 00:00.305
Duration: 00:00.302
Duration: 00:00.303
Duration: 00:00.305
Duration: 00:00.301
Duration: 00:00.301

fpGUI code:
var
  i: integer;
  s: TDateTime;
  e: TDateTime;
begin
  s := Now;
  for i := 1 to 1000 do
  begin
    if (i mod 2) = 0 then
      button2.backgroundColor := clRed
    else
      button2.backgroundColor := clBlue;
    fpgApplication.ProcessMessages;
  end;
  e := Now - s;
  writeln('Duration: ' + FormatDateTime('nn:ss.zz', e));
end;

Martin

Martin Schreiber wrote

tbutton1.Color := cl_Red else tbutton1.Color := cl_Blue;

That's cheating. A button is smaller than a panel (w:200 h:100). ;-) Just joking.

MSEgui and fpGUI are double buffered (Graeme, please correct me if I am wrong with fpGUI).

Yes, all painting in fpGUI is double buffered. Just goes to show Martin - it pays to use custom painted widget sets. ;-)

Regards,
- Graeme -

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

Source is available from SourceForge.net and you can get it as follows:

svn co https://fpgui.svn.sourceforge.net/svnroot/fpgui/trunk fpgui

You can compile from command line or via Lazarus IDE. More detailed instructions are in <fpgui>/src/readme.txt file.

Via Lazarus
src/corelib/x11/fpgui_toolkit.lpk

Via command line
src/build.sh

The fpGUI UI Designer project file is located in
<fpgui>/uidesigner/uidesigner.lpi
Alteratively you can compile from the command line as follows: cd <fpgui>/uidesigner
fpc @extrafpc.cfg uidesigner.lpr

fpGUI requirements are low:
X11 & Xlib dev packages
xft dev package (fpGUI only supports anti-aliased text under X11)

Regards,
- Graeme -

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

Martin Schreiber wrote

> fpGUI, current trunk, button with caption, compiled with -B -O3 Duration: 00:00.305 Duration: 00:00.302

Umm, so there is some space for improvement in fpGUI. I'll try and find that stray 100ms. :)

button2.backgroundColor := clBlue; fpgApplication.ProcessMessages;

I wonder if the call to ProcessMessages in the cause of the 100ms stray... I don't require that line in fpGUI. Just added it in, and it added +-40ms to my timing results.

Regards,
- Graeme -

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

Martin Schreiber wrote

On Tuesday 11 November 2008 14.09:08 Martin Schreiber wrote: > Some more competition: ;-) > > Suse 11 32bit, AMD Athlon XP3000+ 2.15GHz, ATI Radeon 9200SE

Fedora 3 (hardly updated) 32 bit, kernel 2.6.20, Intel CoreDuo 2.4 ....

ok here is qt/gtk2 comparision, current trunk, don't know what are you talking about but here are results ;)

QT:
Duration: 00:00.333
Duration: 00:00.332
Duration: 00:00.330
Duration: 00:00.326
Duration: 00:00.326
Duration: 00:00.327
Duration: 00:00.326
Duration: 00:00.326

GTK2:
Duration: 00:00.735
Duration: 00:00.736
Duration: 00:00.738
Duration: 00:00.736
Duration: 00:00.736
Duration: 00:00.735
Duration: 00:00.734
Duration: 00:00.735

qt/gtk2 code:
var
   i: integer;
  s: TDateTime;
  e: TDateTime;
begin
   s := Now;
   for i := 1 to 1000 do
   begin
     if (i mod 2) = 0 then
       button2.Color := clRed
    else
       button2.Color := clBlue;
      Application.ProcessMessages;
   end;
   e := Now - s;
   writeln('Duration: ' + FormatDateTime('nn:ss.zz', e));
end;

zeljko

Same code without ProcessMessages (qt/gtk2)

QT (can you imagine this ;) )
Duration: 00:00.025
Duration: 00:00.025
Duration: 00:00.026
Duration: 00:00.025
Duration: 00:00.025
Duration: 00:00.025
Duration: 00:00.025

GTK2

Duration: 00:00.394
Duration: 00:00.397
Duration: 00:00.390
Duration: 00:00.390
Duration: 00:00.394
Duration: 00:00.393
Duration: 00:00.396

zeljko

Yes, I was just starting to look at some more timing and hit on that one myself- I hesitate to call it luck. Any mouse activity (not just clicks) over the test form (but not over the title bar) freezes the program for several seconds.

As a working hypothesis, the "Big Freeze" I've seen at the start of execution isn't anything to do with form initialisation, the program runs fine until the pointer is moved onto the form to press the "x1,000" button.

I wasn't entirely joking in my earlier rant: some loss of performance over a remote connection is tolerable. Lockups aren't.

These test are way to short for a reliable test, they should run at least a minute.

Marc

Yes I get the same under GTK1, but it doesn't actually redraw (update the screen) on every iteration, so that doesn't count. :)

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

Source is available from SourceForge.net and you can get it as follows:

Thanks. I'm going to first on SPARC then will come back to this.

So nvidia (nv) or ati (radeon I guess) or intel? I'd like to know the exact setup. Thanks...

Now don't get me wrong.. there's nothing wrong on going to other solutions (even ones which have cost as products) if your situation warrants it. I have also sometimes used different solutions where time didn't permit to fix the various FPC/Lazarus problems (for commercial projects).

What I don't like is when people try to sort of "blackmail" their problems into attention by statements like you did before regarding "we'll be forced to go elsewhere". This isn't a demand driven development model, bugs are fixed on personal mood/itch basis, not on someone "customer" needs (although majority and critical bugs obviously get more attention).

So if you think your money/time is best spent elsewhere, fine, but don't make a crybaby out of the decision. If you decide to stay and help with the problem then even better of course :)

NOTE: opinions here are my own

Ale? Katona wrote

So nvidia (nv) or ati (radeon I guess) or intel? I'd like to know the exact setup. Thanks...

In that case research it based on the fact that test machines include- working from memory- a Compaq ProLiant 3000, Compaq AP550 and IBM ThinkPad T22 all with onboard graphics, and a Sun Ultra-60 with 2x Creator-3D. The System used as an X terminal yesterday was an IBM PC 310 running an older version of Slackware, and today was a Sony Miaow running NT.

Sorry, but right now I'm working on other things and am also hoping to find time to eat.

2008/11/11 Ale? Katona :

i think you are misunderstanding mark, here. the fact that he is taking the time to test and write detailed emails _is_ his contribution. the hardest part of solving the problem is pinpointing it, in many cases. this problem might not even be related to lazarus, i guess.

henry

Fair enough, but I think that puts me in a position that I need to state my policy and that of the people I work for and with.

My policy is that I would prefer to build up enough competence in Lazarus and FPC to be able to make a worthwhile contribution to them.

Our policy is that we don't want to be forced into supplying equipment and services to our customers which carry unfavourable technical and contractual baggage. Roughly translated, we don't want to embed MS OSes in x86 kit unless it really is inevitable :-)

We need to eat, and if it gets to the point where the time I'm putting into dragging myself painfully up the learning curve prevents me from doing concrete development and system management that is going to be a problem. Fortunately I don't think we're particularly near that, but I regularly find that "real work" intervenes in things that are far more interesting and knocks me offline for days or weeks.

I think you are being slightly unfair characterising Lazarus, and by extension other open-source projects, as being driven entirely by goodwill rather than by enlightened self-interest. The bottom line is that we like Pascal-style languages, we value the integrated design and debugging that Delphi championed in its days of glory, and for a whole lot of reasons we want those facilities on platforms that Borland never took seriously.

Now I'm trying to do my bit keeping things going on SPARC, in part because it's a representative non-x86 architecture so is worth attention but also because- at present- it's comparatively easy to get SPARC-based systems which go rather larger than x86-based.

Finally, I would thank you not to mis-quote me. You claim that I wrote "we'll be forced to go elsewhere". I did not write that, what I put was "I'm in a position where I find myself wondering whether I should start looking at C# or possibly Embarcadero's current offering" which I think is fair comment. We should all be doing that now and again, not so much to try to woo new "customers" but simply to ensure that there was not some much-appreciated and easy-to-implement facility which was being overlooked.

I just wish I could do more. But I'm working on it :-)

Mark Morgan Lloyd wrote

I then copied the application over to the PDA again. The program load time (i.e. from tapping the icon to the start of drawing the window) was much better, but disappointingly the execution speed was not observably different, i.e. it still took a second to draw the window.

I've sent Andy over the same test program that I've been running under Linux. Apart from (possibly) the high-precision timer there's nothing special in there so he should be able to compile and run it.

If he sees performance problems with my code, i.e. it's a basic drawing-speed issue rather than something application-specific, is there any other WinCE/PocketPC user who could take both the source and binary by direct email in an attempt to see what's going wrong?

2008/11/12 Mark Morgan Lloyd :

you can send it my way. i've got an acer n30 that i've used with lazarus before, so it wouldn't hurt testing on that.

henry

Henry Vermaak wrote

you can send it my way. i've got an acer n30 that i've used with lazarus before, so it wouldn't hurt testing on that.

Thanks, I'll drop him a note to make sure he sees this.

H?ctor Fiandor Rosario wrote

Dear Mark, my congratulations for yor work in LFP. I am very happy with this compiler and really, it was very easy to migrate from Delphi5 to LFP

I don't know why you're thanking me- I certainly don't deserve any of it. :-)

There's a long list of the people that matter in the IDE's "About Lazarus" box, and I can assure you that I am as indebted to them as you are.

I never ment to say it's good-will based. The itch part means it's based on personal needs as well of course. The point was it's not based on 3rd party needs or requests (at least not "enough").

Fair enough about the quote, but the wording you used originally made the impression of blackmailing on me, that's where the original tension is from.

I understand your position and the original message now, and to explain my reaction, we get some people here which when their personal needs are not met (usually bussiness driven people), end up being all negativist about the project and start a sort of mini-war about how they'll go to <insert other project here> and how ours sucks etc. usually very immature reactions.

The original misconception was on my side though, I misinterpreted your message as being somewhat blackmail-ish while you were simply stating a decision (the main reason I think was that you mentioned concrete alternatives which led me to believe you ment to do some sort of "they're better" statement).

As to the problem of Gtk2/LCL speed, it's still quite possible there's a bug in LCL which does some unnecessary drawing/signals in gtk2 (this was so in the past, but on my end/setup was fixed). Many people get problems with remote lazarus tho, but I'm not sure if it's only Lazarus/LCL or also other gtk2 programs. Also as I said before, gtk2 performance in general depends heavily on many aspects including the drivers, theme, it's version and settings in X.org (for examply my "miraculous" speed is actually result of using the EXA accelmethod).

I have no idea about CE, the only time I used lazarus CE apps was to test my lib in an emulator (so it was slow enough by itself).

Mark Morgan Lloyd wrote

If he sees performance problems with my code, i.e. it's a basic drawing-speed issue rather than something application-specific, is there any other WinCE/PocketPC user who could take both the source and binary by direct email in an attempt to see what's going wrong?

Hi,

I would be interested in taking a look at the application. I am one of the developers of the wince interface.

Gmail won't take .exe or .zip with an exe inside, so change the extensions to close similars, like winzip and winexe.

On Thu, Nov 13, 2008 at 12:36 PM, Felipe Monteiro de Carvalho

Gmail won't take .exe or .zip with an exe inside, so change the extensions to close similars, like winzip and winexe.

Yeah, that is damn irritating!!! Plus they don't even do a good job of it. I attached a .tar.gz with only source code in it. The email got rejected saying it contains and executable!! Dumb idiots!

As an alternative, use the good old method of manually base64 encoding or uuencode your attachments and paste them into your email as standard text. How sad that we need to resort to the stone ages because ISP's and people like GMail can't find better solutions to virus. Everybody should simply switch to Linux and kiss viruses goodbye! :-)

PS:
FPC comes with a base64 and I think a uuencode/decode units.

Regards,
- Graeme -

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

Ale? Katona wrote

Fair enough about the quote, but the wording you used originally made the impression of blackmailing on me, that's where the original tension is from.

That was certainly not my intention and I apologise without reservation to anybody who took it that way.

However if somebody had said "C# won't do what you want because it doesn't have a decent form designer or integrated debugger" it would certainly have reinforced my preference to stay with Lazarus.

My position is that if somebody wants a feature in a piece of open-source software and has commercial resources they should sponsor its development with a bounty. I've never said "I want this feature", I admit that I have rather thrown my hands up in horror when something doesn't work (e.g. hiding the menu bar in gtk1), stops working (SPARC in 0.9.26) or is implausibly slow (e.g. gtk2 to a remote X screen). If somebody doesn't have commercial resources they should use their free time to learn how to add the facilities they want. If somebody has neither commercial resources nor free time I guess a bit of charity is in order, but they certainly shouldn't /demand/ anything :-)

As to the problem of Gtk2/LCL speed, it's still quite possible there's a bug in LCL which does some unnecessary drawing/signals in gtk2 (this was so in the past, but on my end/setup was fixed).

I don't think that speed is really the issue. The "Big Freeze" after mouse movement is far more serious, and using Wireshark I've not seen LAN traffic during this- I might be wrong and will revisit if I've got time.

Many people get problems with remote lazarus tho, but I'm not sure if it's only Lazarus/LCL or also other gtk2 programs.

I think it's specific to Lazarus in this case since I've not seen other problems with Debian "Lenny" which defaults to gtk2, and I almost invariably run this to a remote screen. It could be some rarely-used facility in the gtk2 libraries that is only being used by the LCL, but that is tantamount to saying it's a Lazarus problem.

Also as I said before, gtk2 performance in general depends heavily on many aspects including the drivers, theme, it's version and settings in X.org (for examply my "miraculous" speed is actually result of using the EXA accelmethod).

Understood, and I think that the significant difference in gtk2 performance between the two machines I was using as "X terminals" (I prefer that term because so many people get confused by discussion of what a server is in this context) suggests that at least part of the speed issue is dependent upon properties or facilities negotiated between gtk and X. However as I've said I don't think reduced performance is the significant issue here.

Going back to your earlier question about display types, both systems that I was using as X terminals for test purposes are probably far too old to have significant hardware acceleration- certainly as is understood today. The IBM PC-310 is reported by lspci to have an S3 86C864, the Sony Maiow is reported by NT to be a NeoMagic MagicGraph 128XV; in both cases they are operating at 1024x768x16 (I think) and have about 2Mb RAM. Obviously the video in Sun systems is custom, there are issues on that platform about what kernel versions support acceleration for GLX that I think aren't relevant to the current discussion; the IBM has a Savage which again has acceleration issues which I don't think are relevant since in general I'm not using it as a display device. The remaining Compaqs have onboard video, I might be able to replace the 3000 with something marginally newer from our hardware store but I don't think the details are relevant.

I need to press on with a bit of USB hacking to keep people happy at this end, I'm also trying to revisit 0.9.27+gtk2 on SPARC. If I can I'll try to look at the menu bar issue with gtk1, but the "Big Freeze" almost certainly needs more familiarity with the LCL's innards than I will be able to build up in finite time.

Thanks for that, I believe Andy is watching the list (even though he still can't post) and I'll make sure he's aware.

Mark Morgan Lloyd wrote

I can't help notice that IDE 0.9.26 compiled for gtk2 crawls, I've not yet investigated the speed of gtk2 apps. Is this being slowed down by

Just to confirm... I just tried running gtk2 based Lazarus IDE (0.9.27). And yes, it's unusable via a remote X11 connection. Huge delays in user interaction.

Yet other GTK2 based applications do not have this issue. I managed to run programs like gEdit, Firefox etc without such issues. So it's definitely a Lazarus specific issue.

Regards,
- Graeme -

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

The current situation with 0.9.27+2.2.3 on SPARC appears to be as below.

gtk1: Bus error in object inspector attempting to create an event handler.

gtk2: IDE operation appears OK but bus error during compilation.

Both raise an exception and fail to exit (I also see this on ARM).

I'm afraid I don't have backtraces for these, I need to get a copy of 0.9.27 onto a more accessible development machine- something I'm happier doing now that my desk system is back on a usable 0.9.24.

Unfortunately my fastest SPARC only has gtk1 on it- I could probably fix that by changing distro but there's only so many problems I can cope with at one time.

I'll try to get onto this in a few days but I'm likely to need some help. Please don't kick me too hard :-)

Runs both locally and remotely. I had to tinker with the -Fu in extrafpc.cfg to compile, so far I've only used 0.9.24 and haven't tried x86.

I'll put more time into this presently, but after what I've seen over the last few days I think getting LCL+fpgui complete would be an admirable endeavour since it looks as though otherwise we will be at the mercy of gtk1 being discontinued and gtk2 being hobbled by excessive overhead. It might even be a good default widget set, with gtk2/Qt/Carbon etc. being selected where the target distro and window manager are known.

Mark Morgan Lloyd wrote

Runs both locally and remotely. I had to tinker with the -Fu in extrafpc.cfg to compile, so far I've only used 0.9.24 and haven't tried x86.

Excellent. :-) Could you pass on those changes to extrafpc.cfg, so I can add it in.

overhead. It might even be a good default widget set, with gtk2/Qt/Carbon etc. being selected where the target distro and window manager are known.

A few others have suggested this to me as well, but that's up to the Lazarus developers and how quickly we can get LCL-fpGUI implemented and stable. The huge benefit of LCL-fpGUI will be bug fixing and feature support. No need to limit the widget set to a specific version of the GUI toolkit. Plus if there is a bug or some implementation difference in fpGUI it could easily be tweaked, whereas with GTK2, Qt etc you are out of luck.

Regards,
- Graeme -

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

Strange, I woukld expect the buserrors independent of widgetset. Setting an eventhandler is something IDE code does and it doesn't need a widgetset for that.

:)

Marc

Graeme Geldenhuys wrote

Excellent. :-) Could you pass on those changes to extrafpc.cfg, so I can add it in.

Working from memory, -Fu../lib becomes -Fu../lib/sparc-linux

Noting that Lazarus has the option of building with fpgui, what's the current situation- does anything at all functional come out of it? The option could be useful when I buckle down to look at the 0.9.27+SPARC issue.

2008/11/14 Mark Morgan Lloyd :

the extrafpc.cfg files still need to be changed for the examples, i think.

it should be something along the lines of -Fu../lib/$fpctarget/fpgui

henry

Mark Morgan Lloyd wrote

Working from memory, -Fu../lib becomes -Fu../lib/sparc-linux

Thanks. In recent revisions of fpGUI repository I changed the output directory to use CPU-Target instead of hard-coding the output. This is very handy for sharing the same code directory between VMWare sessions or cross-compiling. I must have forgotten to update those files.

Noting that Lazarus has the option of building with fpgui, what's the current situation- does anything at all functional come out of it? The option could be useful when I buckle down to look at the 0.9.27+SPARC issue.

The LCL-fpGUI widgetset is just a test case at the moment or a placeholder. The code that exists at the moment is simply to evaluate how easy such an integration will be, so there is no usable code really. Last time I checked, only TButton, TForm and TEdit was implemented. This will change in the coming year when I start actively work in LCL-fpGUI.

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

> > Working from memory, -Fu../lib becomes -Fu../lib/sparc-linux

...

or cross-compiling. I must have forgotten to update those files.

All extrafpc.cfg files have been updated in the latest fpGUI trunk revision. So it should now compile out of the box.

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

> or cross-compiling. I must have forgotten to update those files. All extrafpc.cfg files have been updated in the latest fpGUI trunk revision. So it should now compile out of the box.

Apropos cross-compiling and noting that I was using a big-endian processor, I did notice that the uidesigner icons were blank but didn't want to mention it until I'd got x86 and SPARC working in parallel so knew what was expected.

On Fri, Nov 14, 2008 at 1:47 PM, Mark Morgan Lloyd >

Apropos cross-compiling and noting that I was using a big-endian processor, I did notice that the uidesigner icons were blank but didn't want to mention it until I'd got x86 and SPARC working in parallel so knew what was expected.

Images support in fpGUI is very basic. In only supports limited format BMP files. Does 'fpimage' included in Free Pascal and used by Lazarus LCL I believe work? If so, then the fpGUI image issues should be resolved when I start implementing fpcanvas and fpimage support into fpGUI early next year.

Regards,
- Graeme -

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

Lazarus uses fpimage for quite a few formats.
If that works, then it should work for fpGUI too...

Michael.

I think this is something that I explicitly need to check in parallel on SPARC and x86. In 0.9.24 on SPARC there is /something/ that raises an exception if the IDE auto-opens forms, I've suspected something to do with glyph handling but have never been able to track it down. Somebody- if I remember correctly- said they didn't see this on PowerPC which like SPARC is big-endian.

Ungh- I'm going to have to set up a "to-do" list :-)

Note also the Vampyre imaging library which is pure pascal and supports a wide variety of image formats (both loading and saving).

I think it's a sort of gaming lib but nothing prevents other uses.

http://imaginglib.sourceforge.net/

I already created a fpGui component to display images using imaging.

The component code: https://luipack.googlecode.com/svn/trunk/luicairo/ The demo:
https://luipack.googlecode.com/svn/trunk/luicairo/demos/luiimage_fpgui It needs cairo_base, cairo_fpgui, cairo_imaging packages found at: https://luipack.googlecode.com/svn/trunk/cairo
It needs imaging. Tested with version 0.24. See readme at https://luipack.googlecode.com/svn/trunk/luipack\cairo\imaging\extra

Luiz

I might be missing something, but I've just noticed that gtk flatly refuses to allow Lazarus programs to be run setuid. Now I see that http://www.gtk.org/setuid.html gives adequate reasons why this is deprecated but there are cases where it is valuable at least during development, and if fpGUI could exploit this niche it could be useful.

I've added this to my todo list so I don't forget and will looking into it later. I can't give it attention now, as I have urgent deadlines at my company that needs attention first.

Regards,
- Graeme -

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