FL gl rendering on software rendering and delayed events

[danielc...@gmail.com]

Hi, Im testing a fltk app with gl in linux guest virtualbox that dont have acceleration, and it dont performs well, the same app in gtk3 performs well in software rendering, so I presume maybe some setting in fltk.

I tested rendering in a fl_window and it performed better, but still have delayed events on fl_drag event which do a gl function thats lagging.

In windows it runs well.

Can you help?

Thanks

[Gonzalo Garramuño]

On 6/27/2025 7:32 AM, danielc...@gmail.com wrote:
> Hi, Im testing a fltk app with gl in linux guest virtualbox that dont
> have acceleration, and it dont performs well, the same app in gtk3
> performs well in software rendering, so I presume maybe some setting
> in fltk.
>

You can do software rendering in FLTK.  In order to use software
rendering with fltk, you should use fl_draw.H functions with a normal
Fl_Double_Window, instead of gl* code.  You will have to handle the
events with your own coordinate system rather than rely on gl* calls for
selections.  If you learn FLTK well, you can trivially create a driver
that translates GL calls to fl_* calls automatically for all your rendering.

> I tested rendering in a fl_window and it performed better, but still
> have delayed events on fl_drag event which do a gl function thats lagging.

That's most likely a problem with your virtual machine you are using or
the way you are using OpenGL.

| In windows it runs well.

If you are running FLTK on Windows natively, that should be expected. 
If you are also running it through a VM, I expect you should see the
same issues as you describe in linux.

--
ggar...@gmail.com

[Ian MacArthur]

I see that Gonzalo has already responded - he'll have good insights... But you might need to give us more insight to what you are doing though, so that we know what to suggest.

Some other random questions and observations from me:

You say that "the same app in gtk3 performs well in software rendering" - can you clarify this, please? What is the gtk3 version doing? Is it also using GL, or is it doing "simple" drawing? 

From the sound of things, I'm guessing the gtk3 version is NOT using GL but is doing "simple" drawing - in which case using the FLTK 2D API directly may work for you.

Or you can try Cairo.

Now, I'm not a huge fan of Cairo, but it does a good job of drawing things, and if you do not have accelerated GL support in h/w then Cairo may well be faster.

Probably worth a try, anyway.

The GL rendering in VBox can be very sluggish in my experience (and also in WSL2, FWIW - for the most part I'm using WSL2 rather than VBox for "linux on windows" things these days, and it mostly works...)

Some drivers will allow VBox (and possibly WSL2) to more directly access the GPU and thus get accelerated performance, so that might be worth looking into. (And ISTR that VMWare had accelerated GL accessible in their VM's for example, though I don't have any VMWare images now...)

However, I don't think the GL rendering should be _that_ laggy, so there _might_ be something less than ideal about how you are drawing things - maybe you can show us more about how you are deriving your window from FL_GL_Window, and what your draw() method looks like, etc.?

[danielc...@gmail.com]

I solved with this:

case FL_DRAG:

static std::chrono::steady_clock::time_point last_event=std::chrono::steady_clock::now();

auto now = std::chrono::steady_clock::now();

auto elapsed = std::chrono::duration_cast<std::chrono::milliseconds>(now - last_event).count();

if(elapsed>50){

  m_view->Rotation(Fl::event_x(),Fl::event_y()); //must not be called much, reduced to 20FPS

  last_event = now;

}

When I drag the mouse it comes a ton of FL_DRAG events, gtk3 must limit that, I think is that. 50ms=20FPS now it is responsive.

Thanks