fltk directfb or directfb2

[danielc...@gmail.com]

Hi, can FLTK be compiled with directFB on linux, to use on an fltk app in an non desktop environment, wich is limited to 512mb ram?

Thanks

[Greg Ercolano]

On 3/16/25 21:18, danielc...@gmail.com wrote:

Hi, can FLTK be compiled with directFB on linux, to use on an fltk app in an non desktop environment, wich is limited to 512mb ram?

    I don't know about the ram limitation, but you can definitely run fltk (and other X applications) without a desktop/window manager using just an X server, which is probably what I would do if I was trying to work with FLTK using a minimal environment, such as for a kiosk, or some kind of dedicated embedded hardware environment. The X server at least giving access to accelerated graphics and keyboard/mouse.

    For directfb, although I don't think we have anything in the main FLTK release stream to support it, folks in the past have integrated FLTK with directfb + SDL (Simple DirectMedia Layer) for mouse/keyboard io; see:
    https://github.com/caramelli/higfxback/blob/master/DirectFB.md#fltk
    https://directfb2.github.io/#fltk
    https://fltk-dev.easysw.narkive.com/vzL7cOHC/fltk-1-1-7-on-directfb
    https://www.mail-archive.com/fltk...@easysw.com/msg00762.html (FLTK 1.1.9 + directfb)

    I don't myself know anything about it though, other than that has all been with the older 1.1.x versions. I don't think the new fltk 1.4.x stream is supported yet. 1.4 introduced a new device driver API that should make it easier to port FLTK to other platforms and support different graphics drivers/media hardware, as is the case with directfb+SDL.

[Ian MacArthur]

On Monday, 17 March 2025 at 04:18:32 UTC danielc... wrote:

Hi, can FLTK be compiled with directFB on linux, to use on an fltk app in an non desktop environment, wich is limited to 512mb ram?

For "small" embedded systems (I'm old, so something with 512MB RAM is not actually small by my reckoning, 512 B would be though!) then I've done a few things over the years.

Using FLTK to drive a "kiosk" mode fixed window layout is pretty easy, on the whole.

I've done this a few different ways, but the upshot is (as Greg suggests) if there is an X-server codebase for your target, or there's any prospect  of "easily" compiling some X11 variant for your target, I'd just use that (probably with no WM, just the server.)

I have this impression that folks think that X11 servers are terribly heavyweight and burdensome - they are not; back in the day we ran X-servers on 50 MHz P4s with a few MB of RAM - most modern embedded SoCs are way more powerful than that...

First time I did an embedded kiosk with FLTK, I tried a few things, but did end up using a bare Xserver and (hold on, checking...) OK, fltk-1.1.5. Hmm, that was a while ago then.

Since then I've done much the same, or in some places used nano-X / nxlib / microwindows where porting across an Xserver looked like too much effort (porting the nano-X stuff is often simpler.)

Um, I think I did some notes about that once upon a time -  here: https://www.fltk.org/articles.php?L1352

OK, even that was a decade ago...

So on the whole, I (personally) think that approach is easier than the directfb/SDL approach Greg mentions, though I know others have gone that way with success. YMMV, as they say.

[Ian MacArthur]

Off tangent...

On Monday, 17 March 2025 at 09:02:59 UTC Ian MacArthur wrote:

 

I have this impression that folks think that X11 servers are terribly heavyweight and burdensome - they are not; back in the day we ran X-servers on 50 MHz P4s with a few MB of RAM - most modern embedded SoCs are way more powerful than that...

I didn't mean 50 MHz P4's here, did I - I meant 50 MHz i486's...

Slow, anyway...

[danielc...@gmail.com]

ok thanks people, Already tested with xorg, it will run well on raspberry pi zero 2w 512mb ram, xorg dont take more than 50mb of ram, it will do. 
Thanks

[Matthias Melcher]

I started re-merging my SDL code which would give you directfb access and not require an X driver. It is planned as an external driver, so the maintenance burden does not fall on the team if SDL dev stops for whatever reason. But TBH, the CMake setup to support a new driver is, um, complex. Adding a flexible interface for an external driver even more so. This will take a while, especially when I add iOS and Android support.

Maybe some CMake Pro has the time and guts to help me with this?

[Ian MacArthur]

On Tuesday, 18 March 2025 at 01:06:16 UTC danielc... wrote:

ok thanks people, Already tested with xorg, it will run well on raspberry pi zero 2w 512mb ram, xorg dont take more than 50mb of ram, it will do. 

Hi Daniel,

Yeah, a pi zero will run X11 "well enough", though not wildly fast...

Is it really as much as 50MB RAM? That seems high to me, though I confess it's been quite a few years since I last actually tried to measure it.

Is that just the bare server, or is there some WM too, that might be pushing the footprint up? (I think the raspbian WM is GTK based, so won't be all that small!)

[danielc...@gmail.com]

Hi people, I'm trying not to use wm to save as much ram as possible, dont need it, the app that Im doing is for a robot, and need graph only for opengl to help programing the movements, when it will be in prodution dont hae screen as all will b automated. I notest when the app is minimized it dont take cpu or gpu effort, so it will run minimized in production.

The thing is, I want to get rid of wm in production, since it will need an considerable ram to run object recognition, but the win->iconize dont work with fltk app directly on xorg, neither do hide as it exits the app when in xorg.

what options do I have here to save ram and cpu and gpu in prodution?

It will be a robot to missionsave.org

Thanks

[Manolo]

Le vendredi 21 mars 2025 à 04:33:33 UTC+1, danielc...@gmail.com a écrit :

The thing is, I want to get rid of wm in production, since it will need an considerable ram to run object recognition,

but the win->iconize dont work with fltk app directly on xorg, neither do hide as it exits the app when in xorg.

Hiding a window doesn't stop the app per se. What happens probably is that your main ends with Fl::run()

and this function exits when the last mapped window is closed or hidden, program then returns from main() and stops.

You can replace the Fl::run() call at the end of your main() by

   while(true) Fl::wait(1000);

That will have your app wait for the next X11 event instead of stopping after your window gets hidden.

[Ian MacArthur]

On Friday, 21 March 2025 at 03:33:33 UTC danielc... wrote:

Hi people, I'm trying not to use wm to save as much ram as possible, dont need it, the app that Im doing is for a robot, and need graph only for opengl to help programing the movements, when it will be in prodution dont hae screen as all will b automated. I notest when the app is minimized it dont take cpu or gpu effort, so it will run minimized in production.

The thing is, I want to get rid of wm in production, since it will need an considerable ram to run object recognition, but the win->iconize dont work with fltk app directly on xorg, neither do hide as it exits the app when in xorg.

what options do I have here to save ram and cpu and gpu in prodution?

Hmm, that's a bit of a surprise - can you tell where the CPU and GPU cycles are going when the app is shown?

e.g. gprof or similar perhaps, or some other profiling tool? 

My experience with using fltk for kiosks was (in general) if the GUI was not "doing" anything, it didn't take much resources at all, so what you report differs from my expectation. That said, I wasn't using GL...

Are you constantly refreshing some animation or model view? If so, I'd guess that'd be the culprit, so pausing the refresh would stop the resource usage. Hopefully!

Manolo suggests replacing Fl::run() with Fl::wait(<long time>) and that could help - though if you are forcing some animation (e.g. via a timer) there's a real chance that Fl::wait() will return frequently (the timer will cause a valid event so ::wait() will trigger...) Try it and see what happens though, and try to profile where the actual "effort" is going!

FWIW, what I actually used to do was run the "bare" X11 server, then map a single FLTK window of size (0, 0, w, h) where (w, h) were the width, height of the screen - in the early days this was typically 640,480 (VGA size, or a decent fit for NTSC composite monitor) or 800,600 (SVGA, or a decent-ish fit for a PAL composite monitor, if you allow a margin for overscan boundaries)

Latterly we tended to use (1024,768) which was a very common display size for a long time...

Anyway, within that, and given that there was no WM, I used Fl_Groups to show clusters of widgets at fixed (x, y) locations, and I could show/hide those groups if I needed to.

I assume you could map a Fl_GL_Widow as a subwindow in this way and then show/hide that as needed? Though I never actually did that back in the day.

If none of that works, the I'd note that some WM are more resource heavy than others... So you might still be able to run a WM without the resource burden.

I have very occasionally used a lightweight WM on a very resource-poor embedded device and it worked, so that may be worth a try too.

In that regard, FLWM is a good place to start (it is also FLTK based) or aewm / aewm2 are ones I've used. There are others, YMMV!

[LM]

I experimented with the FLTK DirectFB fork and using DirectFB in general on my systems a long while ago.  It was a dead end for me.  I had a lot of issues with how programs displayed and made use of the screen with DirectFB.  Also, there was no active support for it at the time.  I've also looked into other X and Wayland alternatives like sixel. I think one of the best bets is nano-x.  You can check out what distributions such as NanoLinux and XFDos have done using FLTK with nano-x.  nano-x can be run in client server mode so you can have a desktop environment, but it can also be used to run standalone apps.  It's much less complex to build than trying to build libX11 and other supporting libraries for X.  Another option if you do want to try going with X would be something like TinyCore Linux's TinyX.  NanoLinux and XFDos use the window manager SLWM which works well on operating systems that can't multitask such as FreeDOS.