RE: [fltk.general] Control the end of Fltk [General Use]

[MacArthur, Ian (Leonardo, UK)]

> The other API I mentioned is Allegro. I use it as a foundation for a
> game engine and it needs to be refreshed constantly at a stable
> framerate.
> I use Fltk as an editor, and I plan to be able to edit stuff on the go
> (that's why I wanted it on the background).
> I'm actually trying my best not modify the widgets from a thread to
> another, I'd rather send data and let the Fltk thread handle itself.

OK, well I wouldn't put Allegro in a child thread either, it really does want to be in the main() thread I think (though it's been a good while since I used Allegro myself.)

However; do you need separate threads at all? That may be complexity you simply do not need.

Fltk doesn't need a thread of its own, all it needs is for the main() thread to call Fl::wait(0.0); every so often.

This can be quite slow, as slow as 100ms or slower may be enough, depends on how dynamic you need the fltk widgets to be.
So long as the fltk widgets only need to respond at "human" speeds, then a very slow "tick" can be enough.

Fltk itself will not impact heavily on your main process (fast and light!) particularly if you don't even trigger it all that often! (Assuming you don't do anything too complicated in your fltk GUI of course!)

So I'd suggest *not* having fltk in its own thread, but just have the main() Allegro thread "poll" fltk every 100ms or so, such that both Allegro and fltk can "run" in the context of the main() thread.

Others have done this before (indeed, even using Allegro IIRC) and the results have been generally satisfactory.

> I've already considered using sockets to communicate between the engine
> and the editor, and it would be really useful if I ever plan to port my
> engine to mobile platforms (or consoles if dreams come true).
> But I'm not very experimented with sockets and I'm afraid it would take
> too much work. So at the moment I just try to make the two threads
> communicate trough a common data block.

Yes, despite my comments above about "polling" fltk from the main() Allegro thread, I do think I would separate the two GUI elements into two distinct processes and use a socket between them.

OK, there is more "up front" complexity, but once it is done it isolates the two processes and makes things a lot cleaner. And, as you say, it may make porting to other targets simpler.
A search of the web will surely find examples of folk setting up IPC over sockets, that might inspire a solution.

But do try the "polling fltk" thing first, since it should work and be fairly simple to tweak your existing code, I expect!

Cheers...



Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Camille B.]

On Wednesday, August 10, 2016 at 6:19:18 PM UTC+2, MacArthur, Ian (Leonardo, UK) wrote:

> The other API I mentioned is Allegro. I use it as a foundation for a
> game engine and it needs to be refreshed constantly at a stable
> framerate.
> I use Fltk as an editor, and I plan to be able to edit stuff on the go
> (that's why I wanted it on the background).
> I'm actually trying my best not modify the widgets from a thread to
> another, I'd rather send data and let the Fltk thread handle itself.

Fltk doesn't need a thread of its own, all it needs is for the main() thread to call Fl::wait(0.0); every so often.

This can be quite slow, as slow as 100ms or slower may be enough, depends on how dynamic you need the fltk widgets to be.
So long as the fltk widgets only need to respond at "human" speeds, then a very slow "tick" can be enough.

Fltk itself will not impact heavily on your main process (fast and light!) particularly if you don't even trigger it all that often! (Assuming you don't do anything too complicated in your fltk GUI of course!)

So I'd suggest *not* having fltk in its own thread, but just have the main() Allegro thread "poll" fltk every 100ms or so, such that both Allegro and fltk can "run" in the context of the main() thread.

Others have done this before (indeed, even using Allegro IIRC) and the results have been generally satisfactory.

I actually already tried that before I tried threading. I encountered an issue : my allegro window started flickering and seemed to stop updating. So I thought "well, fltk doesn't like allegro, let's try threads"

Now you told me it should be fine, I investigated further and it seems this issue happens only when there is a Fl_Gl_Window shown (too bad there's one imbedded in my main fltk window). If I avoid showing anything with a Fl_Gl_Window everything is fine.

[Greg Ercolano]

On 08/10/16 10:44, Camille B. wrote:
> On Wednesday, August 10, 2016 at 6:19:18 PM UTC+2, MacArthur, Ian (Leonardo, UK) wrote:
>
> > The other API I mentioned is Allegro. I use it as a foundation for a
> > game engine and it needs to be refreshed constantly at a stable
> > framerate.
> > I use Fltk as an editor, and I plan to be able to edit stuff on the go
> > (that's why I wanted it on the background).
> > I'm actually trying my best not modify the widgets from a thread to
> > another, I'd rather send data and let the Fltk thread handle itself.

Another possible approach (not sure it's been mentioned)..

If you're just using FLTK as an editor, have you considered running
the FLTK widget in a separate process that just does the editing function
you need?

The separate process would ensure no threading or window manager issues,
and to the user both processes would look like the same app, and be running
with full control / updating speeds.

You can communicate between the processes using a number of techniques,
including IPC, shared memory, pipes, TCP, or simple files + file locking.

For instance if the user changes the FLTK editor's contents, that process
could write those changes to a file, and the main program would see the change
on the date stamp and load the file. File locking between the two processes
would ensure one isn't reading while the other is writing.

[MacArthur, Ian (Leonardo, UK)]

> I actually already tried that before I tried threading. I encountered an
> issue : my allegro window started flickering and seemed to stop
> updating. So I thought "well, fltk doesn't like allegro, let's try
> threads"
> Now you told me it should be fine, I investigated further and it seems
> this issue happens only when there is a Fl_Gl_Window shown (too bad
> there's one imbedded in my main fltk window). If I avoid showing
> anything with a Fl_Gl_Window everything is fine.

Ah, right. Yes, managing GL contexts can be tricky, especially if you have several and they overlay each other, and often depends very heavily on how the GPU implements the GL functionality (such that what works on one GPU with a given driver may not work at all on another, and v.v.)

Is your Allegro context full-screen? Overlaying fltk widgets from the same thread over a full-screen context is likely to be prone to flickering, I suspect.
Actually, overlying the Allegro context at all, if it is updating frequently, might be prone to rendering artefacts.

I'd expect that separating them into two distinct processes should help with that, though even then I'm not certain it would be flicker free in all cases.

I guess you could cobble together a test that just refreshes your Allegro context in one process then run the fltk cube example (or similar) and lay that on top, see how well it plays out.

If that works and is flicker free (and does not perturb your Allegro context) then I'd take that as an indication that splitting your Allegro and fltk threads into two distinct processes would be a solid solution.

Oh, and I see Greg's pitched in reiterating the two-processes approach too. A consensus of sorts...

[Camille B.]

On Thursday, August 11, 2016 at 11:55:28 AM UTC+2, MacArthur, Ian (Leonardo, UK) wrote:

Oh, and I see Greg's pitched in reiterating the two-processes approach too. A consensus of sorts...

The more we discuss about this, the more I get convinced for this approach. I prefer to spend my energy on learning something new and have something stable rather than finding solutions for a situation that was never intented by the api devs.

I'll keep fltk in a thread for a while (because it works at the moment) knowing it is not safe, and then move on separating stuff when I'm done with my current task.

Thanks again for your support.