Marco van de Voort wrote:
On Thu, Feb 06, 2014 at 10:21:12AM +0000, Mark Morgan Lloyd wrote:
One can try to create a GUI for this already remote scenario (independent
processes display to independent sections of the screen), but if the
systems below can't handle it, what's the point?
I agree, with the caveat that an improved X or improved OpenGL on a
suitable architecture could possibly boost performance significantly
without losing API compatibility.
Note that the numbers I cited are already for a framework that is geared
toward this application. In fact, displaying the image eats the bulk of the
cpu time of the machine.
Even if the backend improves, all things must line up to make it possible to
exploit that, which is hard with a general framework. Specially since the
backends also have limitations wrt threads (like e.g. Opengl).
Yes, agreed. And I think that your observation about attainable speed
(i.e. the limits of X and OpenGL) is pretty much the last word in the
debate- at least as far as current PCs and OSes go.
To present a general threadsafe model to the user, that would require
general locking solution in the LCL, which would slow down normal use for
fringe scenarios (if possible at all)
I think that the only thing remotely worth pursuing, bearing in mind the
current state of widget sets etc., would be whether an LCL in a dll/so
animated by its own thread (which MichaelS has already said was doable)
could output to a buffer, which could then be copied in a thread-safe
fashion to the main form. I speculate that even if that was doable,
getting UI events into the background LCL would be difficult, which in
practice would severely curtail the components which could be used.
--
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
