1. 26
  1.  

  2. 7

    The devil is in the details, though. The web-technology-based toolkits of course are huge, but the native toolkits vary widely in size. The problem is that under a cetain size, you start sacrificing very real things like non-Western-language support and accessibility for disabled users.

    But man…the web-technology-based toolkits are huge.

    1. 1

      But man…the web-technology-based toolkits are huge.

      Well, yea.. using a full featured web browser to draw a UI for a ‘native’ app is a silly idea. That’s the trade-off for lowering the “UI toolkit” bar.

      1. 1

        The web-technology-based toolkits of course are huge, but the native toolkits vary widely in size.

        Sciter is interesting because it’s in between. They basically made their own HTML+CSS engine specifically for making desktop apps, and apparently that approach has worked for memory consumption at least.

      2. 2

        I might have missed on the page, but where are the sources for the test located? I would like to run some of them.

        1. 2

          Benchmarks like this really should link to BitBucket/GitHub/SourceHut/whatever with the source code they used.

          1. 2

            Most of the “reasonable” ones in this list (the ones not using a large language runtimes) will have their memory usage dominated by graphical assets (fonts, and maybe textures/buffers derived from them, etc). The actual efficiency of the widget data structures is going to matter little in comparison.

            I worked on an immediate mode gui a while ago (https://github.com/google/flatui) and was proud of the fact that most memory use was transient, i.e. it could layout and render hundreds of widgets while using only a few hundred bytes of memory! (code: https://github.com/google/flatui/blob/master/include/flatui/internal/flatui_layout.h). That is, until you actually try to render something, and fonts/textures dwarf memory usage of the core of the system. Oh, and having to link in lots of i18n libs etc that dwarf the code size of the core gui system.

            So a truely efficient library would need to render all fonts with vectors, on the fly. I presume some of the lower memory use ones may use system font rendering, so it doesn’t count towards their own memory usage, like all the GL based ones.

            Surprised by dear IMGUI, which should be much lower since a) immediate mode can easily be more efficient memory wise than retained mode, and b) it uses a tiny built-in font.

            1. 2

              The numbers next to Dear ImGui are mostly flat cost of SDL + OpenGL/Vulkan setup which need to create multiple framebuffers. Measure of that cost is likely to grow with resolution.

              There’s a line saying: “SDL (14.0 mb)” above it which gives an indication of that fixed cost. Whereas e.g. “Nuklear (rawfb)” is poking into a framebuffer it doesn’t own, and curiously there’s no equivalent “Nuklear (SDL+GL)” for comparaison of those fixed costs. Rawfb is also probably a bad idea for perf reason (we could also render Dear ImGui with software rendering but in most situations it is silly), and users of accelerated graphics API in their app are already paying the flat framebuffer costs. Which is to say that even though that page is correct, caring about those numbers means ignoring the big picture and can be largely misleading. If there was a measurement to do outside of productivity and flexibility, it would be more interesting to measure prolonged cost of equally elaborate apps - but that’s impossible to achieve because no one is going to write equally elaborate apps for all those toolkits.

              1. 1

                Yup makes sense. Would be great if these tests can be run somehow not counting framebuffer costs. Or maybe they can be run forcing each window to be some very small size.

            2. 1

              It would be interesting to know the memory footprint of embedding a web browser control as a GUI solution.

              1. 1

                If most of your apps are using the same toolkit with shared libs, is it still valid to count the RAM used by one process?

                1. 1

                  That’s a really good question. I think the comparisons should just mention that when it’s true of a project. Give the shared and per-instance number.

                2. 1

                  I wonder how Gtk+1.2 would stack up to Motif (or as they called it, at the time, “Bloatif”). Kind of disappointed that Qt is so high.

                  1. 2

                    Along the same lines, I’d love to see the different Qt versions. I assume here Qt==Qt5, but it’s worth noting that Qt has been a useful and widely deployed toolkit since 1.x, which was a lot leaner. (I used to statically link it back in the day.)

                    1. 2

                      Just check the list, it shows Motif and something called ‘GDK’. Since GDK is not a GUI toolkit I can only assume that this is GTK1.x. Motif uses 1.50MB and as such lies between GDK (which is lower at 1.20MB) and GTK+2 (higher at 2.80MB).

                      1. 1

                        GDK is the drawing engine of GTK. I assume that’s using GDK to draw, without using GTK widgets.

                        1. 5

                          This is mostly the case - GDK is used as an abstraction layer between GTK and the underlying system (Xlib on X11). It was more Glib I was thinking about here than GDK. Still, GTK1 was a relatively lightweight abstraction on top of GDK (and gdk-pixbuf) which did not need (nor support) things like Pango, Cairo, ATK etc. It was lighter than Motif but heavier than Xaw (Athena).

                          Another interesting option for this list would be Xview (Sun’s OpenLook widget library) and the related OLIT (OpenLook Intrinsics Toolkit) which I suspect will end up being more lightweight even than GTK1 while still being perfectly usable. The somewhat sparse OpenLook style fits right in with the current flat UI toolkit trend.

                      2. 2

                        I remember working with Motif on…some system, I can’t remember which now…some Unix….that didn’t support shared objects, so Motif was statically linked into every Motif application. Moreover, they didn’t do a good job with the archives, so every application had a minimum size of like 2-3MB. This was back when that was an enormous amount of space.