On 02/04/2014 07:10 PM, Hans-Peter Diettrich wrote:
Right, nobody tries to support threads in GUI related libraries,
because this doesn't make sense.
IMHO it does make sense in certain applications.
The one my colleagues did is a "user interfaces application" for a huge
(including many PCs plus hundreds of small embedded controllers)
embedded system, that of course features many complex internal states
that rapidly change.
Here the user can select a big number of "state display windows" to be
shown on his - say - four HD-screen wide MDI-like GUI.
Originally the "state display windows" were just normal Windows done
with normal means provided by the VCL (this application at the moment is
done in Delphi).
But as the customer requests got more demanding, the count of the "state
display windows" increased and their content got more complex. As a
result the GUI got too sluggish to be usable. A really hot eight core
engine did not help a bit.
Multithreadding the GUI would had helped, but as this is not available
they finally did a "multi-application upgrade" and which does work great
but needs a huge overhead managing the overplayed Windows and the data
transfer (via a database) between the applications.
-Michael
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
