>Sure; but the Fl::lock() is a mutex, so you must only take it immediately 
>before you want to modify the widgets, and you release it as soon as possible.
>You never hold the lock for any longer than is necessary, and you do nothing 
>but fltk GUI operations within the lock, so there should be no scope for 
>That said, if you need to be handling incoming data asynchronously (and at a 
>high rate) you want to be separating that out from the GUI update process 
>anyway - 
>see Edzard's note on queuing up data for processing, then dealing with that at 
>"user rates", not at input rates.

Nice ideas ; actually the separation is done from the pipe, which buffers 
update requests.
Explicitly buffering is much more elegant. Thanks.


fltk mailing list

Reply via email to