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.
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.
I'm afraid I disagree with that even more, since when you play a video
you're relying on hardware decompression which you can't reliably
characterise as either single- or multi-threaded. Believe me, I've got
Linux etc. on so many odd and ageing systems around here that I
regularly come up against the suppurating lacerations that were
"bleeding edge" until some developer lost interest and didn't stitch it
up, and in my experience the thing that's most likely to work is DVD
playback because the data stream is (as I understand it) sent via a
backdoor to the graphics chips bypassing most of the kernel and X.
Having said which, I'm not unreservedly siding with MichaelS's position,
since unless it completely bypassed any existing widget set (and
preferably drew directly to the framebuffer) it could be screwed at any
time by off-project developers (i.e. the Gnome, Qt or Windows teams).
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
