On 03/18/13 08:00, memoryl...@tin.it wrote:
> Hi all,
> forgive me but here is another question, not-so-evident for me.
>
> You have to realize a blinking message, or an object which periodically swaps
> two images :
> think of an alarm icon.
> The alarm is sounding, and the icon keeps alternatin
Hi all,
forgive me but here is another question, not-so-evident for me.
You have to realize a blinking message, or an object which periodically swaps
two images :
think of an alarm icon.
The alarm is sounding, and the icon keeps alternating red/yellow horn images
until the user pushes the ack bu
>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
>> Each whole page is a group-derived object ; I keep a list of pointers
>> to these objects and jumping to another page is easy.
>> Just make the current group invisible and make visible another.
>> The redraw() caused by the bargraph goes to the current visible "page
>> group" ; a typical plant c
> Messages from the plant data driver can arrive at different rates (say
> from 200 ms up, depending on what is written in the config file) ;
> if I fire a redraw() each time I receive the bargraph level my CPU
> utilization for the graphics app goes from 4-5% to 60%,
> so I simply redraw() when
> Each whole page is a group-derived object ; I keep a list of pointers
> to these objects and jumping to another page is easy.
> Just make the current group invisible and make visible another.
> The redraw() caused by the bargraph goes to the current visible "page
> group" ; a typical plant can h
> In my first app I used Fl::lock, but when the app is growing I have to
> be careful not to create deadlocks, as threads can communicate with
> each other.
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
memoryl...@tin.it schrieb:
> My app is multithreaded ; the main() loop and some other working
> threads, receiving / sending data and doing calculations.
>
> The question: what is the correct way to fire a graphics update from
> a thread ?
We see, there are several correct ways. For measurements m
Albrecht wrote:
> http://www.fltk.org/doc-1.3/classFl__Widget.html#ac92191cba5d17ae34bfc346d2126c9f2
> to damage a particular region (like invalidateRect would do).
It works !
Now forcing a damage to the bargraph parent() passing to it the coordinates to
invalidate.
Removed, for testing, the pre
Me:
> > The question: what is the correct way to fire a graphics update from
> a thread ?
Albrecht:
> Others will probably chime in and tell you more about programming with
> threads and FLTK.
Ian:
> Ah... That quite possibly means me then...
:-)
> Firstly, a caveat: Rendering to the display dev
> > The question: what is the correct way to fire a graphics update from
> a thread ?
> Others will probably chime in and tell you more about programming with
> threads and FLTK.
Ah... That quite possibly means me then...
OK, at a high level, it goes something like this:
Firstly, a caveat:
On 18.03.2013 10:51, memoryl...@tin.it wrote:
> Hi all,
> just to have confirmation of what I am doing.
> My app is multithreaded ; the main() loop and some other working threads,
> receiving / sending data and doing calculations.
>
> The question: what is the correct way to fire a graphics update
Am 17.03.2013 22:17, Chris Russ wrote:
>>> Upon further investigation, the documentation says that the only way to get
>>> transparency (and 100% transparency at that) is with an Fl_Pixmap (say, a
>>> GIF file), and that is definitely NOT RGB. Even so, would that work where
>>> this fails, alb
Hi all,
just to have confirmation of what I am doing.
My app is multithreaded ; the main() loop and some other working threads,
receiving / sending data and doing calculations.
The question: what is the correct way to fire a graphics update from a thread ?
My work (omitted all sanity checks):
-
Hi all,
thanks for the observations.
Ian wrote:
> I *think* what I'd do is create a group (probably with a FLAT_BOX type) that
> contained just the required widgets - I'd populate this at runtime with
> widgets as required based on reading the config file.
> The redraw would then be sent to th
15 matches
Mail list logo
