On Tue, 4 Feb 2014, Michael Schnell wrote:
On 02/04/2014 01:39 PM, Sven Barth wrote:
Upon creation of the QApplication class it remembers the thread ID and
every GUI widget is checked that it is owned by this thread ID as well.
Certain events like rendering are also checked for the thread ID.
While I don't exactly see the point (as each thread of the application will
have it's own thread id and thus should be handled as "unrelated"), I am sure
that you do know what you say, denying the possibility in question.
Anyway this is really bad news regarding the performance of KDE, QT etc (and
consequence the LCL) on multiprocessor systems:
Doing multiple automatically updated widgets will perform a lot faster when
done in multiple applications than in a single one. (We did check this with
Delphi/Windows: same here.)
Sorry, but I think you are totally misdesigning your system.
The GUI is for use by humans. That means that there is no point whatsoever
in updating the GUI more than 10 times per second: the human eye cannot
process information faster than that, let alone that the brain can grasp
the *meaning* of what the eye has seen in such a short time.
Designating 1 GUI thread to update the entire screen 10 times per second should
therefor
a) be entirely possible with any GUI widgetset.
b) be complete overkill for any human operator.
if I play a video at full HD, 1 thread handles the screen display. It works
just fine,
and probable needs to transfer a lot more data to the screen than any normal program
would have to transfer. It would be very surprising if you would not be able to show
some statistical data (or whatever) on screen with the same hardware.
Michael.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
