[Customdrawn] Some patches

Giuliano Colla giuliano.colla at fastwebnet.it
Fri Mar 30 01:50:35 CEST 2012


Here enclosed a svn diff file with a number of patches.

1) I've modified AppRun and AppWaitMessage, in order to achieve a 
behavior similar to that of both GTK and Qt. This change makes mouse 
movements on the form to wake up the main loop (I think this to be 
necessary for hints on controls, and that's what both GTK and Qt do), 
and gets rid of an useless wake up of main loop each second. No adverse 
effects that I can tell. Most changes can be reverted by unsetting 
/CD_X11_UseLCL_MainLoop/.

2) I've fixed form repositioning on the screen, by removing a harmful 
XTranslateCoordinates in customdrawnforms_x11.

3) I've fixed the crash at the end of the program by modifying 
EvClientMessage  always in customdrawnforms_X11. I left there a lengthy 
explanation on what SendCloseQueryMsg does, which can be suppressed 
without hesitation.

4) Again in customdrawnforms_X11 I've modified ShowHide, to fix the bug 
which didn't hide or close the second form in nonandroidtest.

5) I've fixed the double slashes on some font paths. Just a cosmetic 
fix, because Linux doesn't care, and TT_Load doesn't tamper with paths.

6) I inserted a different mechanism to handle timers, because I was 
unhappy with a timers behavior, which is, well, let's say, less than 
perfect. A resolution of one millisecond, and errors in the order of one 
second are a bit contradictory. I tested with a small application, and I 
compared the results with those obtained with GTK2 and Qt. Also GTK2 
shows errors, but by far much smaller, while Qt is reasonably accurate.

Basically there are two flaws:

    * GetSmallestTimerInterval isn't the best way to handle timers, if
      you have more than one. If two timers start approximately at the
      same time one with interval 700, the second with 1000, when the
      first one expires, the next to fire is the one with larger
      Interval, because it expires after 300 ms.
    * Handling the timers in the AppWaitMessage (i.e. in the main
      thread) makes timing too much disturbed by external unpredictable
      events, like mouse activity on the form, other X events, OS
      scheduling, etc.

I tried to solve at least the first one by using a different technique, 
which I've been using since the dawn of times in my real time systems. A 
queue of timers, kept in order of firing, so that the head of the queue 
is always the first timer to handle. The queue is built as a double 
linked list, so that insertion and deletion are very fast. Actually, if 
there are no disturbances, the timing is much more accurate (even better 
than that of Qt), but when there are too many X events, and maybe some 
repaints, the timing becomes quite bad. Not a big step forward. One can 
revert to the old situation, by unsetting /CD_X11_UseNewTimer/.

The real solution would be to handle timers in a separate thread, which 
isn't disturbed by main thread events, and just send an appropriate 
message if and when a timer expires. In this context my queue could be 
much more useful than now. Other "native" widgetsets run in their own 
thread, or multiple threads, and this allows cleaner solutions. After 
all we have multitasking since more that forty years, multiple core 
CPU's since at least ten years: we're not obliged to put everything in a 
single thread as it was customary fifty years ago, when computers were 
powered by vacuum tubes instead of IC's.

That's all about the patches. I've also began to look what is required 
for ATI-SPI and ATK. I gathered that GLoop is only the top of the 
iceberg, and maybe not even of the right iceberg, but I'll tell in more 
detail another time.

Giuliano


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/customdrawn/attachments/20120330/b93b837a/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: commit.diff
Type: text/x-patch
Size: 19014 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/customdrawn/attachments/20120330/b93b837a/attachment-0002.bin>


More information about the Customdrawn mailing list