On Thursday 13 December 2007 01.28, Giuliano Colla wrote:
[...]
> 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).
>
Don't forget MSEide+MSEgui:
http://sourceforge.net/projects/mseide-msegui
MSEgui has several possibilities to synchronize worker threads with the main
GUI thread.
First there is application.lock/unlok which works on a mutex. The main
eventloop acquires the mutex on start of a new round of the main eventloop
and releases it after it gets idle.
Secondly there is application.synchronize which runs a callback in a
try/finally block with application.lock/unlock.
Thirdly there is application.postevent in order to send messages to MSEgui
components. The posted events are feed into the main event queue and are
delivered to the component in context of the main thread.
application.postevent is thread safe and does not block.
tmsecomponent.postcomponentevent and asyncevent can be used for convenience,
tmseform tmsedatamodule have onevent and onasyncevent where the messages can
be handled in context of the main thread.
Fourthly there is FPC synchronize with the problem that checksynchronize is
called once in onidle of then main event loop. One can call
application.wakeupguithread to enable processing but there is a race
condition.
Worth to mention is teventthread with its own message queue.
The graphic subsystem has its own locking mechanism so it is possible to draw
onto off screen canvas (pixmap or printer) from worker threads.
Martin
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
