FLTK vs NTK

[Dirk]

There is a really nice project based on FLTK here:

https://non.tuxfamily.org/

It uses the NTK toolkit, which is a fork of FLTK:

https://non.tuxfamily.org/wiki/NTK

Due to some community issues it seems offline at the moment, but the
code is also here:

https://github.com/falkTX/ntk

Make me wondering if some enhancements of that project could be merged
into FLTK 1.4?

[Bill Spitzak]

FLTK really really really should switch to Cairo. There needs to be some work done to check what the speed issue is. 

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/36046b64-6ee4-3f2b-95f1-3cdeea2329b4%40gmail.com.

[janezz55]

cairo is not without blemish, it has bugs. Though the raster part by and large does work, the GL backed certainly does not. Not to mention the other backends. You need to do some thinking. I tried to do it, but gave up due to crashes in the GL backend, which was my primary target. It could have made FLTK soo fast, or so I thought.

[Dirk]

On 7/13/21 12:32 AM, Bill Spitzak wrote:

FLTK really really really should switch to Cairo. There needs to be some work done to check what the speed issue is.

Sounds good.

Here is another interesting audio project that uses NTK:

http://openavproductions.com/luppp/

On Mon, Jul 12, 2021 at 5:56 AM Dirk <appel...@gmail.com> wrote:

There is a really nice project based on FLTK here:

https://non.tuxfamily.org/

It uses the NTK toolkit, which is a fork of FLTK:

https://non.tuxfamily.org/wiki/NTK

Due to some community issues it seems offline at the moment, but the
code is also here:

https://github.com/falkTX/ntk

Make me wondering if some enhancements of that project could be merged
into FLTK 1.4?


--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/36046b64-6ee4-3f2b-95f1-3cdeea2329b4%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CAL-8oAjYCGUwTznXy%3DHLLrxJJQ3QKYN1Do1_gKchEmHnEr45uw%40mail.gmail.com.

[Dirk]

> target. It could have made FLTK soo fast, or so I thought. --

Note, I'm not a experienced programmer, but the git commits already give
insights on how he tried to improve speed and implement cairo I guess.

https://github.com/falkTX/ntk/commits/master?after=720d8d33200ebd030df700c6c7a5a9cdf4581c03+139&branch=master

[janezz55]

> Note, I'm not a experienced programmer, but the git commits already give
> insights on how he tried to improve speed and implement cairo I guess.

The thing is, having GL on your side gives you a lot of leeway in
terms of performance.

[Albrecht Schlosser]

On 7/13/21 12:32 AM Bill Spitzak wrote:

FLTK really really really should switch to Cairo. There needs to be some work done to check what the speed issue is.

I managed to build NTK with a small patch (see ntk.patch). The latest version uses Cairo exclusively (if I didn't miss anything).

This could be a base for comparisons of FLTK (X11) vs NTK (Cairo).

Unfortunately some of the newer test programs are missing, others are outdated or can't be built. NTK is based on FLTK 1.3.0 (yes: 0, zero) which makes it hard to compare directly, but it's a beginning...

How to build NTK:

If anybody is interested, I did something like this:

1) download (git clone) NTK
2) $ alias waf='python3 waf'
3) $ waf configure --prefix=/usr/local/ntk --enable-debug --enable-gl [ --enable-test ]
4) $ waf build

I believe you need python3 to build (using `waf`) but I'm not sure, I didn't test with python2. Use `waf --help` for options.

You may need to adjust your PATH and maybe LD_LIBRARY_PATH to run the executables. Everything gets built in a subdirectory named 'build' (and build/fluid). I used `(sudo) waf install` to install in /usr/local/ntk but you may want to install in default (system) locations as well (if you like it and dare to do it). It's pretty well separated from an FLTK installation (no guarantee) - fluid is named 'ntk-fluid' etc., header files are installed in include/ntk/FL. `build/ntk-chtheme' can be used to change the "theme" and color config.

`waf` is a python script (included). All bundled libs have been removed, as well as forms compatibility mode and the separate libfltk_cairo. I built everything on Linux - I don't know if it works on other platforms.

The standard FLTK (1.3) test and demo programs are not built in the default config, they need to be enabled explicitly, and not all demos built w/o errors.

AFAICT the original author Jonathan Moore Liles decided to remove much stuff w/o taking care of backwards compatibility (as we do), like Xdbe and some other "special features". The Theme stuff (FLTK: Scheme) is totally different, ...

Screen shot of 'valuators' demo follows:

[Dirk]

If you build the original non-daw project, NTK gets included (gitmodule)
and build by default. On Linux you don't need a patch AFAIK to build it,
at least I didn't.

It's developed and tested on Linux only AFAIK.

https://github.com/theGreatWhiteShark/non/tree/f76de32c449bf60b6805468542075d58d2517580

https://github.com/theGreatWhiteShark/non

If you walk through the NTK commits, backwards compatibility was not a
goal I think indeed:

https://github.com/falkTX/ntk/commits/master?after=720d8d33200ebd030df700c6c7a5a9cdf4581c03+139&branch=master

[Albrecht Schlosser]

On 7/14/21 11:54 PM Dirk wrote:
> If you build the original non-daw project, NTK gets included
> (gitmodule) and build by default. On Linux you don't need a patch
> AFAIK to build it, at least I didn't.

Most of my patch was needed to build the test and demo programs which
Jonathan likely didn't take much care of. The difference why I needed a
patch might have to do with the fact that I pulled the latest updates.
There were some changes related to the latest (included) waf version.
But that's only a guess.

[Webb Hinton]

There are some nice commits here:

• Get rid of ugly FL_EMBOSSED_LABEL and FL_ENGRAVED_LABEL. 
• Add themes.  
  
• Shrink the shadow of FL_SHADOW_LABEL  

I know themes are a bit of a stretch but I really feel like the embossed menus labels are obtrusive, and that "shadow" styled widgets shadows that are too large (could be aboue 1/2 the size).

+1 for cairo as well. 

Anyone know if they included some kind of flexbox solution as well? I don't explicitly see a commit for such a feature, but wouldn't be surprised if they ran into that issue. 

[Bill Spitzak]

It's also find to scrap xdbe and overlay support, that is long obsolete and even when it worked it became clear that they are slower than just using X images (except on Irix which is where this was all first writte). The implementation of FlDoubleWindow should be part of the driver. This is because Cairo does double buffering anyway. So does OpenGL. Probably the Windows stuff does too. And I know the Mac does.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/1b11cca4-382d-4c2c-914b-7eea11eadc47n%40googlegroups.com.

[janezz55]

There are options other than cairo out there. You are discussing ancient commits. I would argue for flexibility, ability to choose libraries other than cairo to draw an app.

[janezz55]

Why not just make writing display drivers easier? If it was up to me, I'd remove any and all cairo support from FLTK and only provide an optional display driver. But currently, the example display drivers are largely incomplete and even broken.

[Albrecht Schlosser]

On 7/15/21 8:17 AM janezz55 wrote:

There are options other than cairo out there.

Maybe. Please tell us which ones we could (should) use and what their advantages are vs. using Cairo. Particularly WRT drawing speed. Patches welcome!

You are discussing ancient commits.

Yes, sure. We're discussing commits of a fork that's been done almost 10 years ago.The latest commit with 'cairo' in its title is dated '2013-07-30'. Most of the real work was done until September 2013 (148 commits), the remaining 17 commits were bug fixes, small improvements, some for speed and some were build system (waf) related.

But what's wrong with this? If we see advantages in such code, then even older code would be fine.

Note: I read every commit of NTK and IMHO Jonathan did a very good job. Thank you, Jonathan!

I would argue for flexibility, ability to choose libraries other than cairo to draw an app.

Flexibility: our driver model in 1.4 is just that: flexible.

You can derive your own driver from an existing one and write your own drawing functions, using your own graphics library. It's not that easy but doable. Then you can load this driver at runtime and there you go. Basically. In practice the internal driver stuff is not public but I assume that the necessary parts could be made public so users (!) could eventually add their own graphics drivers. You can always compile and build your driver code using non-public FLTK headers anyway.

That's why we are talking about using Cairo. It's just one more option in our driver model. The ongoing Wayland port utilizes Cairo for drawing anyway.

If we're talking about speed comparisons we have three options:

1) use the new Wayland driver (work in progress) which uses Cairo
2) use NTK solely for speed comparison (it's mostly FLTK compatible)
3) implement our own Cairo driver (see note below)

Note: The Fl_Cairo_Graphics_Driver is already there, we'd only need make it available as the standard display driver. I don't know if there are some missing pieces (maybe clipping etc.) and how much work this would need but it should be doable.

Note to readers: NTK is not suitable as a FLTK replacement. It's based on FLTK 1.3.0 (2012) and has many incompatible changes. The main target platform was (AFAICT) Linux, I'm not sure if it can be used on Windows or (current) macOS.

[Albrecht Schlosser]

On 7/15/21 3:49 AM Webb Hinton wrote:

There are some nice commits here:

• Get rid of ugly FL_EMBOSSED_LABEL and FL_ENGRAVED_LABEL.

That's not an option for us. We need to keep these for backwards compatibility, but nobody needs to use them.

• Add themes.
  

Themes, Schemes, etc. Jonathan did a good job. He understood that our FLTK "schemes" and "themes" are two different things. He chose to call the FLTK "Schemes" in NTK "Themes" and added "Color Schemes" as a setup option (note that I deliberately changed some colors):



The selection of "Color Schemes" is as follows:



So, what I think most people call "themes" (dark theme, light theme, etc.) is called a "color scheme" in NTK, and what FLTK calls "Scheme" (mainly the box drawing style) is called a "Theme".

But no matter what it's called, it's good and flexible. And the implementation of FLTK Schemes -> NTK Themes is done in a similar way like that I was thinking to do in FLTK as well...

• Shrink the shadow of FL_SHADOW_LABEL
  

This might be considered, likely as a user option (again: backwards compatibility).

I know themes are a bit of a stretch but I really feel like the embossed menus labels are obtrusive, and that "shadow" styled widgets shadows that are too large (could be aboue 1/2 the size).

See my comment above.

+1 for cairo as well.

Yes, this is being considered.

Anyone know if they included some kind of flexbox solution as well? I don't explicitly see a commit for such a feature, but wouldn't be surprised if they ran into that issue.

The only new widget I saw was (from commit log): "Implement new Fl_Panzoomer widget, for panning and zooming around a thumbnail instead of scrollbars". Other widgets often used in audio related software like different valuators and sliders have been changed considerably.

[Manolo]

Yes, the new Wayland platform code contains a complete implementation of a Cairo-based

FLTK graphics driver. That code is mostly platform-independent once an adequate cairo_surface_t

object has been created for the running platform.

That code could be used as a platform-independent FLTK graphics driver,

with possibly some more work for its text-related part which contains some platform-dependent parts (The Wayland

code uses Pango to provide fonts and draw Unicode text).

The Wayland-platform code has Cairo draw directly to a memory buffer (created by new unsigned  char[]).

In contrast, and according to my understanding, NTK uses an X11 Cairo surface in which Cairo calls Xlib

to draw to an X11 drawable, which is presumably memory managed by the X11 server.

I've no idea what to expect in terms of speed difference between these two approaches.

[janezz55]

> Maybe. Please tell us which ones we could (should) use and what their advantages are vs. using Cairo. Particularly WRT drawing speed. Patches welcome!

There's so many of them: openvg, thorvg, nanovg, skia, agg (anti-grain geometry), blend2d, even Qt could be used as a backend and there are many others. I didn't have patches in mind, but perhaps a donated display driver. This display driver idea should be better supported, in my opinion, with more (working!) and non-trivial sample drivers. My favorite of the libraries is, if course, nanovg and it would be nice to see a Qt backend. All of these libraries were inspired by cairo, but cairo is not the only choice anymore. I am against using any particular library, I am for flexibility.

> Flexibility: our driver model in 1.4 is just that: flexible.

In theory, but not in practice. I believe the code of the sample display drivers is too trivial and in part not working.

[Albrecht Schlosser]

On 7/15/21 9:37 PM janezz55 wrote:
> > Maybe. Please tell us which ones we could (should) use and what
> their advantages are vs. using Cairo. Particularly WRT drawing speed.
> Patches welcome!
>
> There's so many of them: openvg, thorvg, nanovg, skia, agg (anti-grain
> geometry), blend2d, even Qt could be used as a backend and there are
> many others. I didn't have patches in mind, but perhaps a donated
> display driver. This display driver idea should be better supported,
> in my opinion, with more (working!) and non-trivial sample drivers. My
> favorite of the libraries is, if course, nanovg and it would be nice
> to see a Qt backend. All of these libraries were inspired by cairo,
> but cairo is not the only choice anymore. I am against using any
> particular library, I am for flexibility.

Thanks for these pointers.

> > Flexibility: our driver model in 1.4 is just that: flexible.
>
> In theory, but not in practice. I believe the code of the sample
> display drivers is too trivial and in part not working.

Android, SDL, pico, and whatever are only starting points, not meant to
be entire, working drivers. If that's what you mean, I agree. They may
not be working as-is, but that's what they are meant to be - only a base
to work off of it. Android may be working already but I didn't have an
opportunity to test it. Matt is probably working on it but AFAICT he's
too busy with other (real life) stuff.

Someone else is now working on an SDL driver.

I disagree that the driver model is not flexible. You can write your own
driver. Using the pico driver is possible but not recommended (it's only
a minimal base driver with certainly bad performance). You'd need some
work to establish a "real" graphics driver.

[Dirk]

On 7/15/21 12:11 PM, Albrecht Schlosser wrote:
> Note to readers: NTK is not suitable as a FLTK replacement. It's based
> on FLTK 1.3.0 (2012) and has many incompatible changes. The main
> target platform was (AFAICT) Linux, I'm not sure if it can be used on
> Windows or (current) macOS.

It's probably most useful for audio people. Developed on Linux indeed,
but I know people tried to build Non-Daw / NTK for macOS, but I'm not
sure if they succeeded (yet).

[janezz55]

Albrecht, I checked Fl_Cairo_Graphics_Driver you were referring to and I think it's a disgrace, I doubt it even works. I think I see obvious bugs and missing functionality (like font/text drawing support). It can't be even called a driver.

[duncan]

I checked Fl_Cairo_Graphics_Driver you were referring to and I think it's a disgrace, I doubt it even works. I think I see obvious bugs and missing functionality (like font/text drawing support). It can't be even called a driver.

The introduction of the driver architecture into FLTK-1.4.x to clean up

the previous #ifdef code confusion that supported a smaller number

of systems is still a work in progress, and there are only a few devs.

FLTK could benefit from your experience and passion to move forward.

Create a fork, supply pull requests or patches. Help to improve things.

[janezz55]

I think this 2D drawing domain is a kind of minefield, cairo does provide a future-proof solution, but not the most performant one. Otherwise, everyone is rolling their own thing, skia for Google/Chrome, pathfinder for Firefox, thorvg for Samsung and several hobby projects to spice things up. I have no passion to explore this further. I was just looking for something fast and future-proof. I don't mind FLTK's slowness, but I can't write a speedy custom control (using cairo's GL backend) either due to too many bugs in cairo's OpenGL backend. The only thing I could see myself doing is a display driver for nanovg, just a bare minimal one to see if I can get some speedups drawing large interactive controls, but I am not sure of that either.

[janezz55]

Sadly, it appears that if you have performance requirements, Qt makes for the best choice for your gui.

[imm]

On Sun, 18 Jul 2021, 12:44 janezz55 wrote:

Sadly, it appears that if you have performance requirements, Qt makes for the best choice for your gui.

Really? That has, very much, not been my experience.

Qt is a fine toolkit, and it's cross-platform support is good (like fltk) but I've never found Qt to be lightweight, nor particularly performant 

Can you describe the drawing you were doing in your test, and show us the metrics you gathered, so we can better understand where the perceived slowness might arise?

Cheers.

--
Ian
From my Fairphone FP3

[janezz55]

My only metrics are subjective, Qt has had these classes for some time now:

https://doc.qt.io/qt-5/qopenglpaintdevice.html
https://doc.qt.io/qt-5/qquickpainteditem.html

These will obviously outperform any "usual" implementation. Yes, fltk
supports opengl and it even has a small gl drawing api, but I'm just
after fast 2d drawing, w/o having to issue GL commands myself and
fltk's api is too modest for my needs. I came to the conclusion that
there is no standardized and universally supported accelerated 2d
drawing api, cairo's GL backend is buggy, the only other good
alternative would be skia. The other problem would be to make fltk
work with a library such as skia, make the gui draw with skia, write a
display driver. fltk can't draw its controls into a Fl_Gl_Window
instance, but Qt can into its GL windows. Otherwise, yes, Qt is a huge
bloat-bomb, but I don't care as long as the 2d drawing is fast.

[imm]

Ah OK, so not timings for a specific set of tasks... Hmm, that makes it tricky to know what best to suggest.

Fltk's own controls are (as far as possible) rendered using the platform-native APIs so are generally about as fast as the platform can do. This is also largely true for fltk's own 2D drawing API.

But, as you say, it (fltk's drawing API) may be too limited for really complex scenes, of course.

And not anti-aliased on Linux, though it is by default on OSX/MacOS, and on WinXX with the GDI+ back-end.

For that (high-speed anti-aliased rendering) I'd reach for GL, since it is very widely supported and hence portable. And generally very fast (host GPU and driver permitting!)

But it's a complex API and sometimes a chore to use...

FWIW fltk-1.4 can render fltk controls on a GL surface (1.3 generally can't though.)

Generally, my feeling is that none of the recent 2D API will ever be as portable and long-lasting as GL has proven to be. Nor as fast, TBH (unless they are just wrapping GL / Vulcan / Metal anyway...)

[janezz55]

FWIW fltk-1.4 can render fltk controls on a GL surface (1.3 generally can't though.)

Really? I am very doubtful, you mean by using the strange GL display driver? I think that code is incomplete, not to mention that's it's for legacy GL versions. Maybe you can point me to a working demo?

[imm]

On Sun, 18 Jul 2021, 17:45 janezz55 wrote:

FWIW fltk-1.4 can render fltk controls on a GL surface (1.3 generally can't though.)

Really? I am very doubtful, you mean by using the strange GL display driver? I think that code is incomplete, not to mention that's it's for legacy GL versions.

Oh, right. I guess from that you maybe haven't done a lot of GL?

The key is that the major platforms only expose a GL API up to about the 1.3 level by default - for anything beyond that, you pretty much have to use one of the extension wranglers, like GLEW or so on.

(Actually, that's not quite true of OSX / MacOS these days, which exposes an API level of 3 or something...)

I usually just use GLEW myself, but there's a bunch of other options.

Anyway, that's why the fltk code only uses the "legacy" API you mention, since that's all you can be sure of having access to "out of the box".

Maybe you can point me to a working demo?

One of the GL samples in the "test" folder renders a simple button on top of a GL surface (in 1.4, not in 1.3).

Can't remember which one though, might be "cube" but I'm not sure. I can't check as I'm on my phone...

[janezz55]

FWIW fltk-1.4 can render fltk controls on a GL surface (1.3 generally can't though.)

Really? I am very doubtful, you mean by using the strange GL display driver? I think that code is incomplete, not to mention that's it's for legacy GL versions.

Oh, right. I guess from that you maybe haven't done a lot of GL?

The key is that the major platforms only expose a GL API up to about the 1.3 level by default - for anything beyond that, you pretty much have to use one of the extension wranglers, like GLEW or so on.

(Actually, that's not quite true of OSX / MacOS these days, which exposes an API level of 3 or something...)

and, ... how about Android and iOS?

 

I usually just use GLEW myself, but there's a bunch of other options.

Anyway, that's why the fltk code only uses the "legacy" API you mention, since that's all you can be sure of having access to "out of the box".

this is why Qt has it's own built-in "GLEW".

 

Maybe you can point me to a working demo?

One of the GL samples in the "test" folder renders a simple button on top of a GL surface (in 1.4, not in 1.3).

Can't remember which one though, might be "cube" but I'm not sure. I can't check as I'm on my phone...

after giving me an undeserved lecture, you're offering some vapor-ware.

[imm]

On Sun, 18 Jul 2021, 23:33 janezz55 wrote:

and, ... how about Android and iOS?

There are wider issues there than the GL API support of course, not least that fltk doesn't yet support them. The main thing is that few of fltk's widgets are well suited to a non-windowed touch first interaction model (I have made touch based kiosk systems with fltk, so I suppose it's feasible for a phone, but I'm not convinced.)

The real crux is, however, Apple's aggressively proprietary attitude to app approval, which essentially precludes anything that uses a third party toolkit. This, to a lesser extent, affects the Play Store too.

 

this is why Qt has it's own built-in "GLEW".

Sure, but it's a "horses for courses" sort of choice and doesn't sit well with fltk's light weight ethos.

Larger toolkits can make that accomodation more readily. Which is why a variety of different toolkits with different capacities is such a useful feature of development now, in many ways.

 

Maybe you can point me to a working demo?

One of the GL samples in the "test" folder renders a simple button on top of a GL surface (in 1.4, not in 1.3).

Can't remember which one though, might be "cube" but I'm not sure. I can't check as I'm on my phone...

after giving me an undeserved lecture, you're offering some vapor-ware.

Oh my goodness! Dear me!

I'm so terribly sorry, l didn't realize I had. 

I thought I was simply answering your questions as best I was able to.

But really, if you try the samples in the "test" folder you'll quickly see the one I mean. Just give them a try.

[janezz55]

this is why Qt has it's own built-in "GLEW".

Sure, but it's a "horses for courses" sort of choice and doesn't sit well with fltk's light weight ethos.

Larger toolkits can make that accomodation more readily. Which is why a variety of different toolkits with different capacities is such a useful feature of development now, in many ways.

Bundling nanosvg and cairo support with fltk was a heavier choice than bundling some glue code would be, IMO.

But really, if you try the samples in the "test" folder you'll quickly see the one I mean. Just give them a try.

I'll check it out.

[imm]

On Mon, 19 Jul 2021, 08:22 janezz55 wrote:

this is why Qt has it's own built-in "GLEW".

Sure, but it's a "horses for courses" sort of choice and doesn't sit well with fltk's light weight ethos.

Larger toolkits can make that accomodation more readily. Which is why a variety of different toolkits with different capacities is such a useful feature of development now, in many ways.

Bundling nanosvg and cairo support with fltk was a heavier choice than bundling some glue code would be, IMO.

Nanosvg is pretty compact, essentially just a header file, and a fairly small one at that, so if you don't use the SVG it doesn't bulk up the code so much.

GLEW can also be reduced to just a header, pretty much, but it's a lot bigger and more complex and ideally needs to be matched to the host platform which can make it trickier to decide what to bundle with a cross platform lib like fltk.

The Cairo hooks are trickier for me as I don't really like how they work, or really see the point of them since it's trivial to get a Cairo context in a fltk window. Of course the Cairo stuff is not included by default anyway, unless you explicitly enable it during configuration, so again has little affect for most users.

But really, if you try the samples in the "test" folder you'll quickly see the one I mean. Just give them a try.

I'll check it out.

They're all just small samples to exercise the various functional aspects, but worth a look.

Both the "test" and "examples" folders have some interesting bits.