Graeme Geldenhuys ha scritto:
On 12/12/2007, Razvan Adrian Bogdan <[EMAIL PROTECTED]> wrote:
The synchronize method is simple but inefficient, it pauses your
thread until the main thread has time to execute your code and could
take some time until it does, i personally also dislike the fact that
Ah okay I see what you mean. If the thread doesn't need to
communicate with the main GUI thread, it will run perfectly. As soon
as it has to talk to the main GUI thread it has to use Synchronize,
which might be delayed by a very busy GUI thread.
Well, on Kylix it was much worse than that. It could be delayed "ad
libitum" by an Idle GUI thread.
Delphi relied on Windows buggy behavior of sending frequent useless
messages around to wake up the main thread frequently.
But an honest to God OS, which doesn't send messages when it has nothing
to say, defeats a design based on bugs.
Of course we may overcome that, by creating your own queue of events
from the thread, and try to process them with an OnIdle event handler,
and wake up periodically the main thread with a timer event.
To discover that if your timer event doesn't change something visual,
the smart thing decides that there's nothing important to do, and stays
Idle, so that the OnIdle handler is never called. My kludge has been to
have the Timer update a Label in a hidden corner of the screen, with a
sequence of - \ | / - . This wakes up the main thread, which then goes
Idle, triggers the OnIdle event, and the queue can be processed. You may
see that this is far from satisfactory.
Up to now I've not yet tested Lazarus with a real demanding threaded
app, but from what I've read about the OnIdle events from Felipe and
others, I'm afraid that the result won't be much different.
So what if the worker thread posts a custom message to say the windows
message queue. Surely that wouldn't cause the thread to be suspended.
The GUI control then simply needs to know about the custom message,
to process it correctly. Could this work, well on Windows at least?
See above. One should use a different design. It's useless to attempt to
make single graphic components thread safe. It enormously increases the
overhead, and the number of possible bugs. What if a widget handled by
thread A is partially covered by a widget handled by thread B, and both
reside on a window handled by thread C? Just think to the amount of
communication between different threads in order to sort out how to
redraw in the proper order.
The screen is a shared resource, so it must be granted exclusive
access. If one thinks of one main thread which besides doing its job
receives messages from all the worker threads, creates a clean queue of
what needs to be done (sorting out what's visible and what not, what
must be drawn and what not, etc.), and passes that to a graphic thread
which is the only one which has access to the display, then you have a
real multithread GUI, which could fill a void in what's currently available.
It could be a challenging project, don't you think?
It just requires a not too large GUI system already existing (such as
fpGui, not Lazarus which is too big to play with) and some enthusiasm
(and also a lot of time, but for my company it could be important, so
some resources could be found).
Regards,
Giuliano
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
