[Customdrawn] LazClock exercise

[Giuliano Colla]

Il 01/04/2012 13:47, Giuliano Colla ha scritto:
> I've run some comparisons to evaluate lazclock performance with 
> different widgetsets, and options.
.....
> I leave it to you to draw your conclusions.
>
>

I don't believe it is fair to raise a problem without trying to offer a 
solution.
X11 backend crawls too slow to be of any use. But rethinking to the full 
picture I believe that the cause and the solution are just under our eyes.

Being Xlib the lowest level interface to the display, all the work must 
be done in the main thread.
Doing things in sequence means being slow. All other widgetsets, and 
backends, take advantage of higher level native functions, so that a lot 
of work is done in other threads, in parallel as much as possible.
But reflecting over it, it came to my mind that Xlib isn't the only way 
to take advantage an X11 server: X11 provides Xt, the X toolkit!

Xt is a toolkit much like GTK or Qt or Windows widgets, provides similar 
functionality (at least the basic ones), except for one important thing: 
Xt widgets are just empty abstract containers. They must be custom 
drawn! You may decide that a widget is a button, and request a 
ButtonPress CallBack, but it's up to you to paint the button in the Up 
and Down state. Just what is needed for a customdrawn widgetset!

Both Qt and GTK can't take advantage of it, because they both are born 
multiplatform.
On the contrary, Motif, which is Unix-only, uses Xt. But in an X11 
backend we don't need to be multiplatform. We may take advantage just of 
what X11 offers.
X11 doesn't provide timers, Xt does. X11 doesn't provide a MainLoop, Xt 
does, but permits to override it, X11 doesn't tell that a button has 
been pressed, Xt does, and so on.
The ugly X-only applications which come with each X11 installations 
(such as Xclock, xsetfonts, xvidtune, etc.) are based on Xt, with a few 
quick and dirty custom drawn widgets, no antialiasing enabled, etc., but 
this means that Xt is always available as a part of all X11 distributions:

[colla at localhost XToolkit]$ ldd /usr/bin/xvidtune
         linux-gate.so.1 =>   (0x008a5000)
         libXxf86vm.so.1 =>  /usr/lib/libXxf86vm.so.1 (0x00101000)
         libXaw.so.7 =>  /usr/lib/libXaw.so.7 (0x001eb000)
         libXmu.so.6 =>  /usr/lib/libXmu.so.6 (0x0012e000)
         *libXt.so.6 =>  /usr/lib/libXt.so.6*  (0x0018c000)
         libX11.so.6 =>  /usr/lib/libX11.so.6 (0x00916000)
         libc.so.6 =>  /lib/libc.so.6 (0x005c8000)
         libXext.so.6 =>  /usr/lib/libXext.so.6 (0x00c0a000)
         libXpm.so.4 =>  /usr/lib/libXpm.so.4 (0x03ec0000)
         libSM.so.6 =>  /usr/lib/libSM.so.6 (0x00c29000)
         libICE.so.6 =>  /usr/lib/libICE.so.6 (0x00cb7000)
         libxcb.so.1 =>  /usr/lib/libxcb.so.1 (0x00a54000)
         libdl.so.2 =>  /lib/libdl.so.2 (0x00754000)
         libgcc_s.so.1 =>  /lib/libgcc_s.so.1 (0x007a4000)
         /lib/ld-linux.so.2 (0x005a7000)
         libuuid.so.1 =>  /lib/libuuid.so.1 (0x00c1d000)
         libXau.so.6 =>  /usr/lib/libXau.so.6 (0x00a4f000)



Taking advantage of Xt would mean IMHO, that only part of the work done 
up to now in customdrawn should be revised, and only as far a X11 
backend is concerned, making it much more similar to other backends.

I attach a list of the man pages related to Xt, just to give an idea of 
the available functionality.

I could take care of it, beginning with only the main form, and leaving 
all the rest as it is, (which won't give any advantage, but will permit 
to familiarize with the tool), and then taking care of the widgets, as 
long as I learn how to deal with a new beast.

What do you think about it?

Giuliano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/customdrawn/attachments/20120401/ab7c5f2e/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ManPages.txt
URL: <http://lists.lazarus-ide.org/pipermail/customdrawn/attachments/20120401/ab7c5f2e/attachment-0002.txt>