Suggestion: Adding a null driver

[Mo_Al_]

Hello 

I'm working on an emscripten driver for FLTK:
https://github.com/MoAlyousef/fltk_emscripten

Which doesn't require SDL or microwindows/NX11 to run on browsers. Only the emscripten toolchain and its headers.
Most of the graphics code is a port of the cairo driver to canvas api. (thanks Manolo for working on the cairo driver).

Here's some example of this on the browser:
https://moalyousef.github.io/fltk_emscripten/

It's far from complete, and still buggy.

However this work requires adding code to the FLTK repo.

I suggest exposing driver headers as public api, maybe under `FL/drivers`. And enabling a CMake option to build against a null driver, which just doesn't compile any of the pre-existing driver code. This would enable creating 3rd party drivers for FLTK without having to add code to the FLTK repo itself.

I would love to hear your thoughts.
Thank you

[Manolo]

Please, specify what driver(s) you would need to add code for. These are the kinds of drivers in FLTK:

-graphics driver

-window driver

-screen driver

-system driver

-GL window driver

-image surface driver

-copy surface driver

At present, the graphics driver is publicly extensible (file Fl_Graphics_Driver.H is in FL/) because it was

thought users may want to define new such drivers. But all other drivers are not publicly extensible.

[Mo_Al_]

I've had to implement the following:

-graphics driver

-window driver

-screen driver

-system driver

To get a minimal things working. The image surface driver is needed for final linking as well.
Emscripten translates OpenGL calls to webgl automatically, so a GL window driver isn't needed. However some "legacy OpenGL" calls aren't supported, such as glPushAttrib, glPopAttrib, glCopyPixels and a few others. So I wasn't able to compile and link the GL driver with emscripten.

[melcher....@googlemail.com]

This is really nice! I read about emscripten, but I never got around to writing anything. Very nice!

As fo the NULL driver, you do have access to the base classes Fl_Screen_Driver, Fl_Window_Driver, Fl_System_Driver, etc. through the FL directory. There are still quite a lot of types that are declared platform specific but outside of drivers, IIRC. What exactly do you need?

As you know, I still have an SDL driver in the works that is already quite nice. I Tok it out of 1.4 to not block the 1.4.0 release, but that was already over a year ago. When we make it to 1.4.0, I will re-merge the SDL code with 1.5, making FLTK available for iOS and Android. And I really love the Web option that you are writing.

So we should make sure that this fundamental changes are good for both drivers and possible other future drivers.

[Manolo]

Le jeudi 29 août 2024 à 15:31:21 UTC+2, melcher....@googlemail.com a écrit :

As fo the NULL driver, you do have access to the base classes Fl_Screen_Driver, Fl_Window_Driver, Fl_System_Driver, etc. through the FL directory.

As of today, the declarations of classes  Fl_Screen_Driver, Fl_Window_Driver, Fl_System_Driver are in src/, only that of class Fl_Graphics_Driver is in FL/.

[Manolo]

Le jeudi 29 août 2024 à 21:59:35 UTC+2, Manolo a écrit :

As of today, the declarations of classes  Fl_Screen_Driver, Fl_Window_Driver, Fl_System_Driver are in src/, only that of class Fl_Graphics_Driver is in FL/.

My opinion is that it's good to keep  classes  Fl_Screen_Driver, Fl_Window_Driver, Fl_System_Driver out

of the public FLTK API so FLTK remains free to modify them without breaking compatibility

with previous FLTK releases. It has proven difficult to construct these classes in the sense that they have often changed. One specially tricky task was to decide what goes to Fl_Screen_Driver and what goes to Fl_System_Driver. This process could evolve freely because these 3 classes are internal to the library.

You can slightly adapt your source code to get access to these 3 header files from their current location

while developing the new emscripten support code, which is more a new platform than a new driver.

[Mo_Al_]

Thanks Manolo and Matthias.

Apart from the driver code, I've only had to minimally modify the platform.H file.
Emscripten also supports native file choosers for the web, so I guess adding support for that will also require adding a Fl_Native_File_Chooser_Emscripten etc.
I'll continue developing the emscripten code until the SDL code is remerged. Then see how to make things work together.

[Mo_Al_]

Hello

Some updates:

I'm able to build all tests, in addition to fltk-options and fluid.

The latest example can be found here:

https://moalyousef.github.io/fltk_emscripten/index.html

I've also uploaded the unittests wasm here:

https://moalyousef.github.io/fltk_emscripten/unittests.html

I'm running into an issue with emscripten_sleep() which is called from Fl_Emscripten_System_Driver::wait(double). I sometimes run into an error when a popup or pulldown is shown which I'm guessing might be a data race I'm causing in Emscripten (unreachable code). I'll have to investigate further.

There are other things which require implementing but which face browser limitations:

multithreaded C/C++ supporting code compiles into a SharedArrayBuffer which most browsers have put limitations on. It requires enabling from the server that's serving wasm files.

Clipboard access also requires clipboard api permissions. 

Native file dialogs must be spawned from html, not javascript (can be simulated though but requires spawning an input element with type "file").

Emscripten supports compiling a virtual filesystem into the binary using preload-file. So currently I have FLTK's filechooser access that, while I think of a way to access the client's filesystem via an input element.

Even with the ability to choose a file from the client, reading the file using the browser's filereader requires that the file be chosen explicitly using the input element.

Printer support can only be done via the browser's print() functionality, which is limited to the current HTMLDocument.

I tried building FLTK with OpenGL support, emscripten translates OpenGL calls to Webgl calls automatically. However that's limited to a common subset of calls shared with GLES apparently. Even when enabling Emscripten's LEGACY_GL_EMULATION, some calls aren't supported like glPushAttrib, glPopAttrib, glCopyPixels and some others.

[Mo_Al_]

For simple apps:

wasm binary sizes are less than 1mb. Memory usage is around 2mb.

Another limitation is virtual keyboard support on ios which is non-existent for any element other that an input or textarea. Since FLTK windows are represented using canvas elements, that means no ios keyboard.

It's also not possible to support a canvas webgl context inside a 2d context. So a Fl_Gl_Window (even if eventually supported), can't be a child of a Fl_Window.

[Mo_Al_]

Hello,

An update:

So I was able to determine the cause of some of the previously mentioned limitations.
1- emscripten_sleep() doesn't support reentrancy:
https://emscripten.org/docs/porting/asyncify.html#reentrancy

It's useful for dialogs and menu windows which call Fl::wait(). The current code works however it might fail at times when spawing a menu window. Code not containing dialogs or menu windows should work ok.

2- Most modern browsers support the clipboard access api. So currently copying text/images should work with FLTK on most browsers.

3- I've specialized Fl_Native_File_Chooser to use the local file access api, so it's able to access the client filesystem. While Fl_File_Chooser works to access the emscripten compiled virtual filesystem (using emscripten's --preload-file and --embed-file compile directives).
The virtual file system is accessible using fopen and such. While the client filesystem needs to read/write using the file access api, which is exposed using fl_read_to_string/fl_read_to_binary/fl_write_to_file (temporary names for now), which are exposed via FL/platform.H.
Note that not all browsers support local file access, only chrome and bing do for the time being, hopefully other browsers will follow suit.

The emscripten platform code now lives in  https://github.com/MoAlyousef/fltk_wasm32_emscripten in branch emscripten.

I've updated the repo https://github.com/MoAlyousef/fltk_emscripten to contain just a simple project which builds 3 wasm files (index, simple, unittests).
Previous links should still work.