Hi, and thanks for your reply !
>> It does work well, but I have the feeling that it is a bit cobbled up
>> in a non-optimal way. What would be a better design ? Maybe spawning
>> a thread for the display (though I seem to remember reading that
>> display was only allowed to be done in the main thread) ?
IMA> If it were me, I would use another thread for this; for robustness,
IMA> the GUI portion would be in the main thread, and would call
IMA> Fl::run().
>> The one thing I want to avoid is "while (check()) { compute(); }"
>> because I would like the emphasis to be on the (non-interactive)
>> computation itself, the display being very secondary - plus it would
>> require storing some additional state, defining compute() in a
>> reasonable way, which would be nice enough to return early, ... I
>> dont't mind for the definition of Image to be complicated, but main()
>> should really be as simple as shown above.
IMA> Yup - sounds fine. That's pretty much what I described, I think.
Well, I don't know much about threads so they frighten me a little -
although, given code like I would like it to be,
int main () {
Image I (200,200,"title");
I.show();
while (1) { I.put (rand()%200, rand()%200, randomcolor()); }
}
the only option I see would be to spawn a GUI thread from within
Image::show(). If I do that, as far as I understand the while() loop
above would have to be within the main thread, which pretty much makes
the GUI thread secondary one, and I understand that this is wrong or at
least not portable. So the only way I see around it is to have the code
look like this:
int run () {
Image I (200,200,"title");
I.show();
while (1) { I.put (rand()%200, rand()%200, randomcolor()); }
}
int main () {
hocus_pocus (run);
}
where hocus_pocus spawns a worker thread running run() and then does
Fl::run(). But I really would like the code to look like the first
version because I don't want the end-user to even know about it (the
display part should be completely transparent).
Or is there a trick which I am not seeing somewhere ? [Come to think of
it, I could use #define to make main into actual_main and then have
always the same main() function, like IIRC SDL does. But again I am a
bit afraid of that, and I would like to know whether it is completely
stupid before trying it and risking losing my mind ;-)]
IMA> If you do thread your code like this, in most cases you will get
IMA> better CPU utilisation since the GUI thread, prone to blocks on the
IMA> display h/w, is separated from the computational heavy-lifting.
IMA> (And threads will usually utilise multi-core CPU's better anyway.)
Ah, that is a very good reason to investigate a bit more. Some of my
drawing code is indeed not so light ...
/v
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
