[fltk.general] R: Re: R: Re: Smooth blinking

[memoryl...@tin.it]

Hi Albrecht,


 Also note that this timer delay compensation works well (i.e. as
 designed) on Linux, but probably not on Windows :-( I did some
 tests a while back, but lost track of it. I can't say anything
 about Mac OS WRT this.

No Windows here, m8 :
just pure Linux amp; microwindows on a 400 MHz PowerPC embedded platform ;-)

Thanks,
regards

Lucio


 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] R: RE: R: Re: R: Re: Smooth blinking

[memoryl...@tin.it]

Hi Ian,
microwindows is a piece coming from the past.
I have already realized several machines running with AMD Alchemy (MIPS), more 
or less same horsepower as the actual one.
It was the usual work of putting together pieces (microwindows + nano-X, 
truetype fonts and so on),
but it works.
Microwindows + nano-X actually is not a project with as much as activity as 
fltk, but it's working.

Maybe another solution could be better now, but I already had to switch 
hardware platform as Alchemy is end of life product :
new schematics, new bios, new kernel (Alchemy=2.4.x, PPC=2.6.x), new kernel 
drivers... and note that MIPS=little endian, PPC = big endian.
I just had sufficient new things, to think of throwing away microwindows + 
nanox.

I was surely tempted of trying X11 server, but now I cannot do this for time 
constraints.
Don't know kdrive, but I'm curious and sooner or later will try it.


Regards
Lucio


 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] R: Re: Smooth blinking

[memoryl...@tin.it]

Hi Greg and Ian,


  Use a timer to blink... but things are not always smooth blinking.
  Not a big problem, anyway... just would like to know if there is a
 clever way to assure a smooth blinking
  (usually we are speaking of small objects).

Not really sure this is what was being asked, but here's a simple demo of 
blinking widgets.

Maybe this is what was wanted?

Yes.
The problem was that, under particular conditions (many redraw of images), my 
blinking could become irregular,
as timers, if I understand well, are all at the same priority level.

The technique you and Greg told me is clear ; will clean up something in my 
(growing!) app and try
to avoid unnecessary redraws.

Again,
thank you a lot for your precious help.

Best regards,
Lucio

 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Bargraph object with Fl_Group

[memoryl...@tin.it]

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 the group, hopefully that would work...!
 With judicious use of groups, you can possibly arrange for some of the 
 widgets to be in another group to reduce the redrawing somewhat...

The parser of the configuration file recognizes the page keyword. Each page 
is a group, which in turn contains all the objects to be visible in a screen:
- buttons to go to other screens
- static images (background, etc.)
- animated images (run/stop/pause images)
- bargraphs
- edit boxes
- etc.

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 have 20-30 different pages.
The main and only window is a Fl_Double_Window.

 What sort of update rate are you looking for?
 If the rate is slow, then redrawing the whole lot, in a double_buffered 
 window, will be smooth and relatively painless.
 Will depend on how powerful your device is of course, but if it is plant 
 control, then animating at a few Hz may be fast enough, 
 without taking too much resource away from other tasks? 
 Humans can't actually respond to inputs much faster anyway, so refreshing at 
 more than a 2 or 3 FPS is just wasting cycles
  - we are not making a movie or a video game here, so we don't need 60 FPS to 
 make things work!

Right. Refresh rate is very slow, no need to run faster than 2-3 FPS.

 You can manage this by controlling the damage regions for your widgets - but 
 you still need to do the redrawing of the damaged regions yourself, the 
 toolkit will not do it for you...
 If the update rate is low, it is probably not worth the extra effort - just 
 redrawing the lot will be simpler!

Now bargraph sends redraw() to the parent (the page group) and it works.
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 the new bargraph value is different from the previous.


Albrecht wrote:

 http://www.fltk.org/doc-1.3/classFl__Widget.html#ac92191cba5d17ae34bfc346d2126c9f2
 to damage a particular region (like invalidateRect would do).

... I missed it, thanks !!

 Agreed 100% ! Don't optimize prematurely. It's much easier and saves a lot of 
 trouble and testing to (re)draw entire groups, unless you
 (the OP) really need(s) it.

Agree with you.
Let's say that for now I resolved with groups. I still have to keep an eye on 
not firing too many redraw() calls, but this is part of the
normal way of programming.
Will have a look at the particular damage() call.
Observations / suggestions are welcome.

Thanks,
best regards

Lucio


 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] Correct way to fire graphics updates from a background thread

[memoryl...@tin.it]

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):

- main:
.
static int fd_refresh[2];
.
pipe(fd_refresh);
SetNonblocking(fd_refresh[0]);
SetNonblocking(fd_refresh[1]);
Fl::add_fd(fd_refresh[0], Do_refresh_callback, NULL);
.
#define CMD_REFRESH 0
.
static void Do_refresh_callback(int fd, void *data)
{
 unsigned int val;
 while(read(fd, amp;val, sizeof(val))  0)
 {
  switch(val)
  {
   case CMD_REFRESH:
   // HERE I can draw to screen !
   break;
   .
  }
 }
.
}

- A thread receives data and wants to update a drawing. It cannot do it 
directly,
so it writes to fd_refresh[1] an integer which values represent what I want to 
do
(full redraw(), partial updates, etc.) .
Fltk then will call Do_refresh_callback and there I will be safe drawing 
anything.

Is this sequence correct ?
Now it's working without (apparent) problems.

Thanks,
regards

Lucio

 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Correct way to fire graphics updates from a background thread

[memoryl...@tin.it]

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 device from any thread other than 
 the main thread is not robust (may work on some systems, will fail in 
 horrible, hard to debug ways, on others, so do not do that.)
I can confirm this. REALLY horrible ways.

 Instead, all drawing is done from the main thread. In particular, note that 
 creating/deleting/hiding/showing windows *has* to be done by the main 
 thread.
 However, if you create your widgets in the main thread, you can alter them 
 from other threads quite safely, if you use the fltk locking methods. You can 
 signal updates between threads using Fl::awake(); there's no need to get 
 fancy with pipe's  and so forth (fltk is handling that internally) and it is 
 more portable.
Here's a simple recipe for this:

- in the main thread, before you create any windows, call Fl::lock(); *just 
once* to enable thread support. (Do not do any more locking/unlocking in the 
main thread, let fltk manage that for you.)

- in a worker thread, if you want to update a widget, do:

   Fl::lock();
   my_widget-change_this();
   my_other_widget-change_that(value);
   etc.;
   Fl::unlock();
   Fl::awake();

And that should update the widgets in a thread-safe way, then flag the main 
thread to manage the redraw sequence.

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.
Nothing impossible, but I found the pipe method a little easier to debug.

 Note that Fl::awake can also be passed a callback function - the main 
 thread will then execute that callback in its context, 
 allowing the worker threads to do some operations that would not otherwise be 
 allowed 
 (e.g. you may be able to use this to create new windows under the control of 
 a child thread, since the actual creation will occur in the context of the 
 main thread.)

This is interesting. I missed it.

 However, that is often not necessary, the simple case I outlined above covers 
 a lot of use cases.

Albrecht and Ian, thank you for your help.
If you are coming to Italy let me know, beer ready for you !

Thanks,
regards

Lucio


 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Bargraph object with Fl_Group

[memoryl...@tin.it]

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 previous bargraph value check (to invalidate very 
often), and the CPU utilization stays low.
Reactivated, for good programming, the previous bargraph value check.

Thanks !!

Regards,
Lucio

 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Correct way to fire graphics updates from a background thread

[memoryl...@tin.it]

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 
deadlocking.
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.

regards
Lucio


 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] Smooth blinking

[memoryl...@tin.it]

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 button.

Use a timer to blink... but things are not always smooth blinking.
Not a big problem, anyway... just would like to know if there is a clever way 
to assure a smooth blinking
(usually we are speaking of small objects).

Thanks,
regards

Lucio

 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] R: Bargraph object with Fl_Group

[memoryl...@tin.it]

So good speaking with you, boys.

Greg wrote:

 If the image is assigned to the bargraph's group, then just telling the 
 bargraph widget to redraw() will do it.
 But if the image is assigned to the parent window, then you'll have to tell 
 the parent window to redraw.
 Be sure to use an Fl_Double_Window to prevent flickering during redraws.

This is exactly what I am doing now.


Ian wrote:
 So long as the background is drawn by your app, then it is feasible to 
 composite the bar graphs and etc on top of it.
 But: If the background is drawn by some other app, or is otherwise outside 
 the control of your app windows, then compositing the graphs and so forth on 
 top becomes Very Tricky.

 For now the simplest solution I can imagine is to redraw the whole parent of 
 my object.
 
Quite possibly: I think we need to understand more about the nature of 
the backgrounds, how they are drawn etc, and from there we can figure 
out how to render the graphs on top of them...

Well, there is no window manager ; I have microwindows sitting over the 
framebuffer and a single fltk application which does everything, so the 
situation is conceptually simple,
because everything is drawn from one single app. Background programs to acquire 
remote variables, but only one app writing on lcd.
I manage all the firmware, from bios to Linux kernel to user interface, so I 
have full control on the machine.

I am trying to create objects as simple as possible : generally speaking every 
object has some functions to animate itself, requesting variables from a 
remotely connected machine.
For example:
Think of a plant which, in its full realization, is composed of 4 identical 
stations (tanks, motors, etc.) .
For each station the plant supervision designer will put:

- one background image (the drawing of the station) with a visible boolean 
coming from remote
- one bargraph (value, min, max, visible boolean)
- one box displaying a numeric value (value, format, visible boolean)
- one multiple-image box representing the run status (off, on, waiting, etc.) 
- (image index, visible boolean)
- one start/stop button
- etc. etc.

Now a plant is smaller and has only two stations: the remote machine will put 
some visible booleans to zero... and the graphics app
will show only the installed stations.

So one can think: I create a group with image, bargraph, boxes and it's done.

I can't do this, because my app has to be general: it's the plant installer who 
knows how the plant is made.
He will create the configuration file for my app (we created a Windows software 
for this), specifying where (x, y) and how big the objects are.

It's the classic supervision software : as general as possible. Windows 
software to visually design the plant -- configuration file -- my embedded 
software
to parse it and show / animate objects.

-
Coming back to the problem: instead of redrawing all the bargraph parent, IMHO 
the key point could be the ability to invalidate only one small portion of 
the parent,
the rectangular portion under the bargraph.

Bargraph::RedrawObject()
{
 parent()-invalidateRect(xBar, yBar, wBar, hBar);
 redraw();
}

First instruction tells the parent to redraw only the part under the bargraph, 
and the second redraws the bargraph.
Obviously this is general: all objects needing some sort of transparency should 
behave this way.

Thanks
Lucio


 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] Bargraph object with Fl_Group

[memoryl...@tin.it]

Hi all,
I am trying to create a simple object representing a bargraph.
It is a simple filled rectangle, derived in a Fl_Group ; the draw method simply 
draw two rectangles,
one with fill color, the other with background color.

All is ok ; now I want to add a transparent background option.
I cannot draw the background rectangle, so when the rectangle is growing all 
is right,
but when the bargraph value goes down...
How can I force the erasing of the filled rectangle before redrawing it with 
the new dimension ?
Any suggestion is welcome.

Thanks all,
regards

Lucio Dona'



 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] R: Bargraph object with Fl_Group

[memoryl...@tin.it]

Ok, ok, it's Friday, need more sleep.
Simply forced redraw() of the parent solved the problem.
It's a bit inefficient, because if the parent is a big window with many 
objects
I have to redraw everything. Masked by redrawing only when the bargraph value 
changes, for now.

Any way to invalidate to the parent only the bargraph area ?

Thanks,
regards
Lucio



Messaggio originale

Da: memoryl...@tin.it

Data: 15-mar-2013 10.34

A: fltk@easysw.com

Ogg: Bargraph object with Fl_Group



Hi all,
I am trying to create a simple object representing a bargraph.
It is a simple filled rectangle, derived in a Fl_Group ; the draw method simply 
draw two rectangles,
one with fill color, the other with background color.

All is ok ; now I want to add a transparent background option.
I cannot draw the background rectangle, so when the rectangle is growing all 
is right,
but when the bargraph value goes down...
How can I force the erasing of the filled rectangle before redrawing it with 
the new dimension ?
Any suggestion is welcome.

Thanks all,
regards

Lucio Dona'



 



 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[fltk.general] R: Re: R: Bargraph object with Fl_Group

[memoryl...@tin.it]

Hi Ian,


 thanks for your answer.
 I am writing to you directly,

Best not - I very seldom reply to off-list posts...
Sorry, will post to the list.

 OK: Then you need to composite the bar graph on top of the image.
 Fltk does not provide support for transparent widgets (yet) as it is a hard 
 thing to do in a consistent cross-platform way, so the best bet may be for 
 you to just blit the image into the box, then render the bar on top of it.
 This is easy and cheap to do, if you are rendering the graph on top of an 
 image your app owns.
 If you want to render the graph transparently on top of (for example) the 
 desktop then you are on your own out there, since fltk can't really do that 
 without a lot of platform specific code...!
 Hope that made sense!
 FWIW, I think Greg's cheat pages have examples of doing some of this, so it 
 would be worth a look...
 http://www.seriss.com/people/erco/fltk/ 

I need a bit of thinking.
I am writing an app for creating supervision screens on an embedded platform.
All is ruled by a configuration text file : it is parsed from my program which 
then creates all the pages, the buttons for page jumps, the graphics objects 
and so on.

In general I do not know what there will be under my bargraph : maybe a 
picture, maybe a filled background.
The situation is more similar to the desktop you mentioned.

For now the simplest solution I can imagine is to redraw the whole parent of my 
object.

Thanks a lot for your observations,
regards

Lucio



 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk