Hello,

Does anyone know what would be the solution for implementing timer support in a X11 toolkit? I already have TTimer support implemented for LCL-CustomDrawn-Windows, Cocoa and Android (but Android is the best tested of them), but it looks like X11 has no support for timers, so I wonder what the best approach would be to solve this.

thanks,

As far as I know, most toolkits do a timeout on the X11 communication handle (using select()) and this timeout is used to implement the timers.

Michael.

Roll your own event loop by calling select() on the XConnectionNumber (which is a file descriptor). You can then use the select() timeout, or use timerfd* functions under linux. Google around to find examples.

Henry

Presumably with the usual health warnings on whether select() updates its parameters. As far as I could tell when hacking serial.pp, Linux does but Solaris (8, 10) doesn't.

Also note that when doing this, you'll have to make sure you check for all the internal connections that X opens/closes. You can do this with XAddConnectionWatch(). The callback will give you a file descriptor that you can add/remove to/from the set of file descriptors you a monitoring with select().

Henry

Indeed. It seems like relying on this is not a good idea. So then using timer_create with pselect is probably the most portable approach.

Henry

wow, I started taking a look at how to do it and as always with anything related to X11 it is terribly complicated ... but luckly I am not alone here using FPC, so I shamelessly stole code from fpgui, hammered it a little bit to fit TTimer and TCDTimer and already have a initial TTimer for X11. If anyone wants to know how I did:

http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&root=lazarus&revision=34350

Gotta love compatible licensing =)

And while we are discussing tasty stuff from fpgui, I added partial xft and fontconfig headers to FPC in rev 19879 They are more correctly reflecting the C headers then the original one from fpgui and a little bit more complete too:

http://fpgui.git.sourceforge.net/git/gitweb.cgi?p=fpgui/fpgui;a=blob;f=src/corelib/x11/fpg_xft_x11.pas;h=22bf3aff39e118a5cfaaf7c255b406755fb1634e;hb=HEAD

It would be good if someone could check the build system, because in that directory there are 2 build systems, fpmake.pp and Makefile, and I dont know which is the active one

Spinning like this is bad news for efficiency and battery life of embedded devices.

Henry

Henry Vermaak wrote

Spinning like this is bad news for efficiency and battery life of embedded devices.

Well, using X11 in an embedded device by itself is a very bad choice =D And that's why it is very rare and linux-based phones don't use it. But what do you mean exactly? Using the timeout 50?

Better tell Maemo they've made a very bad choice, then. It's not just embedded devices, laptops have batteries, too. You're wasting CPU and power just spinning around a loop, so even if your app isn't active, it's still waking up every 50ms. I don't consider this very good programming practice.

Henry

MSEgui has another method with a list of timer events. http://gitorious.org/mseide-msegui/mseide-msegui/blobs/master/lib/common/kernel/msetimer.pas On Linux it uses timer signals to build the time steps with microseconds resolution.

Martin

But presumably only if you are using a timer, in which case that's exactly what the programmer wanted ?

Michael.

Henry Vermaak wrote

Better tell Maemo they've made a very bad choice, then.  It's not just embedded devices, laptops have batteries, too.  You're wasting CPU and power just spinning around a loop, so even if your app isn't active, it's still waking up every 50ms.  I don't consider this very good programming practice.

I tested with top and it doesn't even show my application in the top 20 users of CPU.

Anyway, I changed in this rev:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&root=lazarus&revision=34354

It now adjusts the interval acoording to the installed timers, up to a maximum of 1 second.

No, he's got a hard coded wakeup, since he wants to support multiple timers by adding them up (sometimes "guessing" the value). If I set a timer for 1 hour, I don't want the program to wake up every 50ms.

Henry

If I was just interested in linux, I'd probably use timerfd, which would tie in nicely with the select(). For non-linux, using posix timers and self-pipe trick with pselect() would also work, but would be more work.

Henry

You're still "guessing" a timer interval of 10ms to add to the timer if the select() doesn't time out. So your error can be as much as 990ms per iteration of the loop. So much for precision then.

Henry

Henry Vermaak wrote

You're still "guessing" a timer interval of 10ms to add to the timer if the select() doesn't time out.  So your error can be as much as 990ms per iteration of the loop.  So much for precision then.

select() doesn't seam to return how much time has passed, so how do you expect me to know the value when the only thing FPC offers for time counting is Now() and each UNIX goes a wildly different way about this?

I tried to implement GetTickCount as a first step to at least basic time counting support in FPC outside Now, but it was quite hard and I don't care about timer precision that much. If you need a precise TTimer in X11, maybe you could try to implement GetTickCount and GetMillisecondCount. I'd merge the implementation to lazutils, which already has a GetTickCount waiting for a proper UNIX implementation and then I could use it to implement a precise TTimer support in LCL-CustomDrawn-X11.

If not, then it will stay like it is now until someone sends a patch to improve it.

select() on linux will actually modify the timeout (fpc overloads select(), but presumably this will still happen when you use ptimeval for the timeout). You shouldn't rely on this, though, read the man page for more info. This is what Mark was trying to say in his reply to your original message.

you expect me to know the value when the only thing FPC offers for time counting is Now() and each UNIX goes a wildly different way about this?

I've offered a solution in my reply to Martin Schreiber, but fpc doesn't offer functions for posix timers. Perhaps you can check if Marco is in a good mood? Either way you could test it first by knocking up a test in c.

Perhaps it's better to implement a thread based timer?

Henry

In our previous episode, Henry Vermaak said:

Not likely with Linux-only stuff in the same msg. That's where I stopped reading pretty much.

Ummm, that's quite interresting, I hadn't understood in the first time as I hadn't yet experience with select. Looks like a possibility for Linux until a GetMilisecondsCount is implemented.

Perhaps it's better to implement a thread based timer?

Not for LCL-CustomDrawn-X11, I think what is being achieved is already a good base, it only needs to be improved. Threads will probably bring more problems then solve.

Marco van de Voort wrote

Not likely with Linux-only stuff in the same msg. That's where I stopped reading pretty much.

What linux only stuff? Since when does posix mean linux only? Spare us the linux phobia, please. Googling for timer_create bsd shows that at least freebsd supports this.

Henry

In our previous episode, Henry Vermaak said:

I was kidding. I will add a smiley next time.

I'm not anti-changes. I just want to see them as a consistent complete set, and not as a linux implementation with a laisez faire attitude wrt other platforms.

I've been thinking about this myself, and if you don't want bad timers, the most logical route would be to write a scheduler implementation where the scheduler

1) in principle waits till the next registered event (events can be periodical)
2) the wait can be broken (e.g. when a new event is registered, which could theoretically fire before the current wait) because it also blocks on some event. (waitmultiple on sources + tevent on Windows, select on events + pipe on *nix)

MSEgui timer implementation works approximately like that. On Linux it uses libc setitimer() with microseconds resolution to setup the wait time until the next event, on Windows either settimer() or mmtimer timesetevent() if better resolution is necessary.

Martin

Henry Vermaak wrote

embedded devices, laptops have batteries, too.  You're wasting CPU and power just spinning around a loop, so even if your app isn't active, it's still waking up every 50ms.  I don't consider this very good programming practice.

I'm always interested in improvements. The 50ms code was done purely to implement the Application.OnIdle() event. How else can I implement an OnIdle event then?

I think it depends on what you mean with 'OnIdle'.
- An event which occurs once when an application falls Idle.
- An event which is triggered repeatedly when the application is idle.

As I understand it, Delphi and Lazarus implement the former, and don't need a timeout for it.

Michael.

As I understand it, Delphi and Lazarus implement the former, and don't need a timeout for it.

Ops, you are correct, it is a one shot event:

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Forms_TApplication_OnIdle.html

I think I implemented it as a repetitive event. ops =D I guess I'll need to fix this.

But you should not try to compare directly the LCL gtk2 or qt4 widgetsets with fpgui since gtk2 and qt4 do most of the real work. Lazarus now has a X11 interface which can be used for direct comparisons and it uses the timeout. In general I don't fully trust select() to wakeup correctly yet. I guess that more testing would show if it does, but I read in the web that X11 could use more then one file descriptor for communication, so if I use a infinite select() the application could hang in some corner cases.

I think it depends on what you mean with 'OnIdle'. - An event which occurs once when an application falls Idle. - An event which is triggered repeatedly when the application is idle.

fpGUI's OnIdle event used to fired only once, when the application goes idle - but I found it much more useful to have an idle event that fires repeatedly. Maybe I should make it configurable via the fpgApplication instance, so the developer can decide how they want it to work.

Strange statement.

If select() didn't do its job correctly, neither Qt or Gtk could do their job, or any network related program, for that matter.

Michael.

Felipe Monteiro de Carvalho wrote

not alone here using FPC, so I shamelessly stole code from fpgui,

The joys of open-source software. :-)

Well, the latter will consume CPU cycles, as indicated by others... It all depends on what the programmer needs.

Michael.

Strange statement. If select() didn't do its job correctly, neither Qt or Gtk could do their job, or any network related program, for that matter.

It is not about select working or not, it is about how many file descriptors X uses to communicate:

http://fixunix.com/xwindows/91558-xconnectionnumber-select.html#post301681

I don't have time in the foreseeable future to find in which wierd corner case XAddConnectionWatch is necessary and test that a implementation which I come up with works, but Qt could pay someone to stay all week testing wierd corner cases and find the most perfect algoritm. For me, timeouting every second is already more then good enough, it could even be each half second. Already at 50ms I could not see my application with top in the top 20 CPU users (most of which were using zero), so I seriously doubt the battery usage concerns unless someone really measures it.

I was just about to mention that, and would have been very surprised if it did show CPU usage. I have always been careful with CPU usage in fpGUI's event loop.

It now adjusts the interval acoording to the installed timers, up to a maximum of 1 second.

Initially I thought that sounded like a good idea - but doesn't in now do even more processing that without the GetSmallestTimerInterval() function? Doing the timer loop, a math comparison for each timer etc. But realistically it should still hardly register as a blip in the CPU usage, so I guess it should be fine - especially if only one or so timers are ever used in a application.

I already mentioned this, but perhaps you didn't read it. You don't need to test _any_ corner cases, that's the point of XAddConnectionWatch. You get a callback that gives you a file descriptor which you can add/remove to the descriptors you check with select():

http://groups.google.com/group/comp.windows.x/browse_thread/thread/cd32588d173fffcf/4b750082b055422b?q=mity&rnum=5&hl=en#4b750082b055422b

Perhaps you should try powertop.

Henry

FYI, qt and gtk2 uses same source for timers and loops - glib2. http://en.wikipedia.org/wiki/GLib
http://developer.gnome.org/glib/2.26/glib.html
I would try with it before reinventing wheel, because it works on all X11 platforms (even on OS/2 and BeOS) and I'm pretty sure that it's installed by default.

zeljko

Power usage is not only related to how much cpu power you use. Repeatedly waking up the cpu for minor processing also consumes more power than letting letting it stay in a low-power power saving mode.

Jonas

Henry Vermaak wrote

Perhaps you should try powertop.

Thanks for this. I never knew about powertop. I just ran it for a few minutes. A fpGUI base app in idle rates 6th in the "top causes for wakeups" on my system - rated at 4% of total processes running. I have no idea how that relates to actual power usage though. My USB trackball (at 18%) and Firefox (at 16%) rated 2nd and 3th, respectively. The kernel_scheduler got the number one spot with 20+% share of all running processes.

I don't think fpGUI is doing too badly, but also not ideal. I'll see if I can improve that code in fpGUI a bit.

zeljko wrote

I would try with it before reinventing wheel, because it works on all X11 platforms (even on OS/2 and BeOS) and I'm pretty sure that it's installed by default.

Interresting, but I don't think it will be necessary ... in rev 34359 I commited support for XAddConnectionWatch =D And I also don't like very much gnome APIs, although it could be added as an alternative via ifdefs if someone wants to go down this path.

But I could not fix OnIdle to adere to the Delphi specification because that would affect assync call handling since there is only an TApplication.Idle event which handles both. LCL-Gtk2 fires OnIdle like a machine gun in a program with a timer, and I don't know if this is correct or not, it would be good if someone with Delphi could test. If it isn't correct or ideal then maybe we need a
TApplication.PartialIdle (called by Idle too to keep compatibility) to handle things like AssynCall. I don't know where the hint update belongs to, PartialIdle or Idle

The 1 second timeout needs to be kept anyway, because another thread could queue an assync call, so we need to check that periodically.