[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