On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
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.
I'm afraid I disagree. As a trivial example, the position of the mouse
pointer is updated much more often than every 100mSec, not to mention things
like animated pointers and icons. Just because a GUI invites user interaction
doesn't mean that it can't run asynchronously.
You didn't prove anything with this statement. It is obviously possible.
But is it necessary ? I don't think so. For 'simple' things like mouse
cursor, you can do this because it requires no resources.
But complicated information like statistics or information of 20 cameras,
needs time to be processed by the brain in order to react on it. There is
therefor no need to have it refreshed in intervals that the brain cannot
discern anyway. What could possibly be achieved with displaying information
of 20 cameras at 60 FPS ? Nothing, unless you want to brag about your hardware.
I'm not saying that you should wait more than a second, but 1/10th, or
even 1/24th should be ample for the stated purpose, and well within reach
of a single thread.
Based on that I just don't think that what Michael Schnell aims to accomplish
calls for a full-blown multi-threaded GUI architecture. The overhead that
would introduce just isn't worth it. It's killing a mosquito with a cannon.
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
