FLTK 1.5 and SDL3

[melcher....@googlemail.com]

FLTK 1.5 will get an external SDL3 driver that can replace the internal native drivers. This will allow FLTK apps to run on iOS and Android devices without changes to the application source code.

SDL is a cross platform library that provides a way to draw onto the screen (mobile) or into windows (desktop) and receive unified events, independent of the underlying operating system. It's the go-to cross platform library for game and emulator developers. It supports a countless number of operating systems, CPUs, and graphics APIs.

 So, yes, it runs under Wayland just like any other user app, but it does not communicate with Wayland in particular. SDL typically runs in a single window, it always runs full-screen in a single window on mobile platforms. FLTK/SDL will come with its own little window system, so the user can create a popup dialog, for example, even though an Android/iOS device typically has no window system or desktop.

ggar...@gmail.com schrieb am Donnerstag, 27. Februar 2025 um 07:07:30 UTC+1:

Will SDL3 support allow FLTK to use Wayland in some way.  To me that's 
the biggest and only feature I am looking for 1.5+. 

 

On Linux, FLTK already supports Wayland via the Wayland driver since 1.4 . I have not decided yet if FLTK/SDL will support multiple SDL windows. For the start, I will target mobile devices. If there is demand (SDL based games and emulators could use an FLTK window for settings and dialogs), support for multiple SDL windows could be added later.

 - Matthias

[Gonzalo Garramuño]

On 2/27/2025 5:35 AM, 'melcher....@googlemail.com' via fltk.coredev wrote:

ggar...@gmail.com schrieb am Donnerstag, 27. Februar 2025 um 07:07:30 UTC+1:

Will SDL3 support allow FLTK to use Wayland in some way.  To me that's 
the biggest and only feature I am looking for 1.5+. 

 

Sorry.  I did not get enough sleep.  I meant Vulkan not Wayland.

Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

Le jeudi 27 février 2025 à 09:35:52 UTC+1, melcher....@googlemail.com a écrit :

FLTK 1.5 will get an external SDL3 driver that can replace the internal native drivers.

Matthias: what would be an external driver? Would that be different from an additional

set of platform-specific FLTK driver classes (Fl_SDL_Window_Driver, Fl_SDL_Screen_Driver,

Fl_SDL_Graphics_Driver, Fl_SDL_Image_Surface_Driver, Fl_SDL_Gl_Window_Driver,

Fl_SDL_System_Driver) like the Wayland set which was added to FLTK 1.4?

[Albrecht Schlosser]

I think what he meant was that this driver might be in a separate repository to make the normal FLTK distribution independent of the SDL, Android, and maybe IOS stuff. We talked about this and the fact that having to maintain Android specific code had been a problem when we had the "old Android" support with all the pico, SDL, and Android stuff in the same, i.e. in our main FLTK repository.

IMHO this new repository should not become a "real fork" of our main repository but something that can be maintained separately. I imagine that there will be a new branch and that the FLTK `master` branch will be merged from time to time, whenever the "SDL repository" needs an update, or the "SDL branch" will be rebased as needed after pulling in the "upstream" changes. Or something like that, details need to be specified in the future.

[melcher....@googlemail.com]

Manolo schrieb am Freitag, 28. Februar 2025 um 13:13:32 UTC+1:

Matthias: what would be an external driver? Would that be different from an additional

set of platform-specific FLTK driver classes (Fl_SDL_Window_Driver, Fl_SDL_Screen_Driver,

Fl_SDL_Graphics_Driver, Fl_SDL_Image_Surface_Driver, Fl_SDL_Gl_Window_Driver,

Fl_SDL_System_Driver) like the Wayland set which was added to FLTK 1.4?

 

No, it's the same idea, only it is not a built-in driver, but statically linked at compile time. Plus Android needs a Java wrapper and weird linking that has no place in the FLTK repo.

I talked with Albrecht about maintainability. When I was out sick for years, a half baked SDL driver held the active developers back and wasted their time. To avoid this in the future, I want to look into the possibility to link a driver set via an external library. FLTK would get something like a NULL driver, basically a driver set that does nothing useful, but also does not crash. Then any set of drivers can be added by statically linking with a driver library that can be developed separately without interfering with core development.

I imagine it would be possible to have something standardized that mirrors the OpenGL API to allow other 3rd party renderers like Vulkan or Direct3D.

> Gonzalo Garramuño wrote:

> Sorry.  I did not get enough sleep.  I meant Vulkan not Wayland.

To get back to the OP: SDL can be compiled to run with Vulkan. This is kind of backwards, but as the SDL code stands, this would allow Vulkan rendering in any FLTK window or probably more common: Vulkan rendering full screen and FLTK rendering as an overlay.

[Gonzalo Garramuño]

On 2/28/2025 11:04 AM, 'melcher....@googlemail.com' via fltk.coredev wrote:
>
> To get back to the OP: SDL can be compiled to run with Vulkan. This is
> kind of backwards, but as the SDL code stands, this would allow Vulkan
> rendering in any FLTK window or probably more common: Vulkan rendering
> full screen and FLTK rendering as an overlay.

I have made a lot of progress with my Vulkan driver and, if you guys
will accept it, I'll add a pull request probably next month or so.

--
Gonzalo Garramuño
ggar...@gmail.com

[melcher....@googlemail.com]

Yes, that would be great. I can't promise anything though.

One of the biggest issues right now is maintainability. After all, the main reason we don't have SDL2 support was me being absent due to health issues, and with the tiny team we are, nobody was able to take one the project. So we will try to keep new drivers separate from the FLTK core from now on as much as possible, and try to modularize new major features.

I am currently testing a new CMake variable, FLTK_BACKEND_EXTERNAL and FLTK_BACKEND_PATH that is supposed to disable all internal drivers and instead link the direvers given by the path. As usual, this is much more complex than anticipated, but I feel like I am getting somewhere.

Also, if we want to add more libraries, like we did with fltk-images, fltk-gl, etc., we should also do that in an external library.

Is your Vulcan patch a complete graphics driver backend, or is it a a single (sub)window, like the Fl_GL_Window?

[Mo_Al_]

I also like the idea of a null driver and the ability to plug external drivers to it. The emscripten driver code requires some intrusive changes to FLTK's CMake script, some modifications to FLTK's sources, in addition to requiring internal headers which are not part of the public api.

[melcher....@googlemail.com]

I am very much hoping to have Emscripten as a full fledged driver option. That would be awesome!

So between the three of us, maybe we can find a way to get this driver interface working well enough for all three projects. The intention of the whole driver setup was just that, but the original pre 1.4 structure of FLTK did not allow a full separation of drivers and core. Now with 1.5, we can break ABI and modify the API, so this is the time!

My task list currently is:

- (week 14) add FLTK_BACKEND_EXTERNAL and FLTK_BACKEND_PATH for at least macOS, other platforms to follow

- (week 15 (traveling)) create a minimal driver (that does nothing) in an external git repo that links into FLTK with those settings

- (week 16) remove all interferences with the FLTK core

- (week 16) allow external drivers to integrate core drives

- (week 17) write RGB graphics driver

- (week 18) adapt to SDL3

If you guys are interested, I can share the progress with write permission. My changes will be visible in any case in my GitHub repo.

[Gonzalo Garramuño]

El 1/4/25 a las 19:00, 'melcher....@googlemail.com' via fltk.coredev
escribió:

>
> Is your Vulcan patch a complete graphics driver backend, or is it a a
> single (sub)window, like the Fl_GL_Window?

It is three things.  It is a modification to the CMakeLists.txt file to
add FLTK_USE_VK=ON like FLTK_USE_GL (code is almost identical in the
CMakeLists.txt GL path, as Albrecht's code was really easy to follow).

There's also Fl_Vk_Window and Fl_Vk_Window_Driver that handles the usual
vulkan chores (swapping buffers, create commands for drawing, add
optional depth and stencil map).  Finallly there's drivers for each
platform to create the surfaces for each platform -- macOS, X11, Wayland
and Win32.

My code would not benefit from a null driver I think.  It seems to me it
would make things harder.

--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 4/2/25 15:12 Gonzalo Garramuño wrote:
>
> El 1/4/25 a las 19:00, 'melcher....@googlemail.com' via fltk.coredev
> escribió:
>>
>> Is your Vulcan patch a complete graphics driver backend, or is it a a
>> single (sub)window, like the Fl_GL_Window?
>
> It is three things.  It is a modification to the CMakeLists.txt file
> to add FLTK_USE_VK=ON like FLTK_USE_GL (code is almost identical in
> the CMakeLists.txt GL path, as Albrecht's code was really easy to follow).

I'm glad you say that, but that's not all my code. The initial CMake
code was from someone else, then "adopted" by me, and with additions
from Manolo and Matthias.

> There's also Fl_Vk_Window and Fl_Vk_Window_Driver that handles the
> usual vulkan chores (swapping buffers, create commands for drawing,
> add optional depth and stencil map).  Finallly there's drivers for
> each platform to create the surfaces for each platform -- macOS, X11,
> Wayland and Win32.
>
> My code would not benefit from a null driver I think.  It seems to me
> it would make things harder.

The null driver wouldn't be for your code to benefit from, as far as I
understand it. It would be something comparable to an empty (abstract)
base class all other drivers can be derived from, where the abstract
class defines the interface for other classes. Its intention would be to
improve - or enable in the first place - driver maintainability of the
FLTK library. Once the null driver exists, its interface can be used to
build other drivers on it.

Matthias, is this how you plan to design it? Can you elaborate if I'm wrong?

[melcher....@googlemail.com]

Albrecht-S schrieb am Donnerstag, 3. April 2025 um 00:33:48 UTC+2:

The null driver wouldn't be for your code to benefit from, as far as I
understand it. It would be something comparable to an empty (abstract)
base class all other drivers can be derived from, where the abstract
class defines the interface for other classes. Its intention would be to
improve - or enable in the first place - driver maintainability of the
FLTK library. Once the null driver exists, its interface can be used to
build other drivers on it.

Matthias, is this how you plan to design it? Can you elaborate if I'm wrong? 

Yes, that is correct. I am still in the trying-out phase. CMake is so capable, but also so complex that I keep maneuvering myself into dead ends. Gonzalo, I am hopeful that your PR will actually help me to find the dividing line between core, driver, and external driver. Again, this is not meant to cause (much) additional work for you, but to keep the core safe if or when a developer can no longer maintain a driver, and no other developer can take over ;-) 

The null driver is really just a base that would allow FLTK to compile with no driver code linked in at all. It's just another name for a driver base class that is self sufficient. Your Vk driver is probably building on that already anyway.

 - Matthias

 

[Albrecht Schlosser]

On 4/3/25 13:55 schrieb 'melcher....@googlemail.com' via fltk.coredev wrote:

Albrecht-S schrieb am Donnerstag, 3. April 2025 um 00:33:48 UTC+2:

The null driver wouldn't be for your code to benefit from, as far as I
understand it. It would be something comparable to an empty (abstract)
base class all other drivers can be derived from, where the abstract
class defines the interface for other classes. Its intention would be to
improve - or enable in the first place - driver maintainability of the
FLTK library. Once the null driver exists, its interface can be used to
build other drivers on it.

Matthias, is this how you plan to design it? Can you elaborate if I'm wrong? 

Yes, that is correct.

Thanks for confirmation.

I am still in the trying-out phase. CMake is so capable, but also so complex that I keep maneuvering myself into dead ends.

Please let me know by private mail if I can help, or let's have a phone call ...

Gonzalo, I am hopeful that your PR will actually help me to find the dividing line between core, driver, and external driver.

Gonzalo, I suggest to put your code in a branch of your FLTK fork and let us know about it. We can pull and test it even if you don't make a PR. Technically this PR couldn't be merged because it would provide code on a code base that's subject to be changed (add the null driver etc.) but your code in your fork would help to see what we (and particularly Matthias) need(s) to do.

Again, this is not meant to cause (much) additional work for you, but to keep the core safe if or when a developer can no longer maintain a driver, and no other developer can take over ;-)

Yep, I agree, but one of the main reasons is IMHO to simplify core code management w/o having to take care of (a lot of) optional future drivers. The maintenance of "external" drivers would - in my imagination - be done in separate repos. I imagine that such a repo would *include* the FLTK core by a mechanism like CMake's `FetchContent` so you can keep the FLTK core on a specific commit and change this reference only after the driver code has been adjusted to match potential changes in the FLTK core. Hence the responsibility of changes in each driver would be on the driver maintainer and not the core maintainers.

Example: if we decided to add new virtual methods to the core (null) driver, or if we added or changed parameters of virtual methods, then external drivers might need to be adjusted. In such a case each driver could be modified individually and the new core version (git commit/hash) would be changed (in `FetchContent` ) so the driver works on the modified FLTK core. As long as this adaptation has not been done the driver still works with the older FLTK core version (commit/hash).

Note: This is how I *imagine* how this could be done. We need to work out such a scheme to work with.

The null driver is really just a base that would allow FLTK to compile with no driver code linked in at all. It's just another name for a driver base class that is self sufficient. Your Vk driver is probably building on that already anyway.

I imagine that having the null driver in place would even simplify maintaining new drivers because each driver would be isolated from the core code. Once the null driver exists, we'd have a clear and documented interface to build a driver on.

[LM]

Ever since FLTK 1.4 introduced the option for additional backends (with the Android and PicoSDL examples), I’ve been working on a full SDL2 backend. I've made slow but steady progress.  However, I've been stuck following the single SDL window model inherited from the Android and PicoSDL examples.

Screen drawing, fonts and most of the functionality illustrated by the unittests programs works.  The visual output looks very good.  The only part I've been continuing to struggle with is how to deal with situations that need multiple windows such as for drop downs.  I recently switched to a multi-window model and that resolved several issues.  However, positioning, resizing, hiding and moving windows in sync is still very much a work in progress.

Does the new SDL3 backend for FLTK 1.5 have a better paradigm for dealing with the window situation and handling drop downs, menus etc?  

Is there a possibility of combining efforts between the new SDL3 project and what I've done with the SDL2 backend I've been developing?  

I've put a lot of time and effort into getting a working SDL2 backend.  It would improve portability of FLTK to a number of platforms without requiring nano-x.  I’d appreciate any thoughts on how my work might align with the SDL3 backend effort and whether there’s a path forward for collaboration or shared design.

[melcher....@googlemail.com]

SDL2 was removed from FLTK because it was only half way implemented and I was not able to maintain it due to health. I always wanted to reintroduce SDL3 into 1.5, but we were not able to agree on terms, because if I as the sole maintainer of SDL3 would have to stop development again, FLTK would yet again drag around a half baked backend. I tried a backend plugin system, but it was making the CMake process too complicated.

On the implementation side, there are three ways to have multiple window. 1 is the easy one. Use the SDL3 multi window interface and maintain one bitmap or texture per window. 1 is not available on Android and iOS, so we would need option 2: implement a window manager on top of single window SDL3. Option 2a would allocate a texture for every Fl_Window. By keeping track of window stacking, windows are simply drawn bottoms to top. Disadvantage is a large memory footprint for a full bitmap for every window, and low speed for having to copy every window-bitmap to the screen after every redraw - at least fro teh damaged rectangle. 2b keeps a single bitmap for the entire main window, which works as a desktop now, and only the actually damaged regions would be redrawn. Because windows can overlap in irregular ways, one would have to implement clipping regions (as opposed to the clipping rectangles that are part of SDL3), and then only redraw whatever changed (Fl::damage(x,y,w,h), taking clipping regions into account. One would still have to implement a window manager, i.e. draw window decorations and implement window dragging and resizing.

This is all doable, but time consuming, and adds quite a bit of code to FLTK core. I would love to have SDL3 as an externally linkable backend, but that would require a plugin system for backends, which we don't have. In fact, I would love to see *all* backends be plugins. It would stop plugins from reaching into the core FLTK library and keep the user interface aspect cleanly separated from rendering and window management code. Our team is *much* to small to implement that though.

 - Matthias