1. 38
  1.  

  2. 6

    so immediate mode GUI libraries usually just don’t support internationalized text.

    This seems to me like a very big sacrifice, and contrary to what @pekkavaa wrote in another comment, I think it merits a value judgment. Perhaps I missed it in the original article’s explanation, but what advantage(s) does an immediate-mode GUI have that would justify this significant drawback? Is it somehow faster, or just simpler to implement?

    Another area where I think an immediate-mode GUI would struggle is accessibility. When implementing an accessibility API, you are generally expected to provide a persistent tree of UI elements, and then raise fine-grained events when things change in that tree, e.g. when a new element gets the keyboard focus, when an element’s name changes, when a progress bar advances, or when new text appears in a frequently updated text area like chat history. This is much more tractable with a retained-mode GUI. So, outside of the set of applications where lack of accessibility is acceptable (e.g. games), the choice of approach is not merely aesthetic.

    1. 1

      All existing internationalized text shaping libraries are too slow to shape a long document in one frame, so immediate mode GUI libraries usually just don’t support internationalized text.

      Curious if this is a “nobody has taken the time to write a library optimized for the task” type thing, or if there are fundamental difficulties in the task that have inhibited it so far.

      1. 1

        Given how text often isn’t the most prominent part of a game, I could see why support for internationalized text isn’t a top priority for an immediate mode GUI.

        One aspect of immediate mode GUI is that it makes making decisions on the fly about what to render much quicker, so choosing to render one of several different texts based on a language variable doesn’t seem like it’d be fundamentally difficult from an engineering perspective. It’d be harder to get all the text on hand in the first place.

        The example given, of rendering a long document of scrolled text, would also be fairly solvable in an immediate mode context, depending on how you want to trade it off: you could render the text to an image, and scroll the image, you could use a text rendering library in a background thread to build up an image in memory, and then show that.

        I suspect part of why those libraries do not support it is because most immediate mode GUI projects do not have nearly the man-hours put into them that the big players in the retained-mode GUIs do. You’re comparing the work of a few individuals or small teams against the years of work that Microsoft, Apple, Google and Mozilla have put into Win32, HTML, and UIkit.

        Accessibility would probably be a much harder thing to solve for.

      2. 5

        One beautiful example of the “do almost nothing” aesthetics has been explored by cryptographers when they implement multiplication of top of addition (Mostly compute modular exponents of huge numbers, and elliptic curve cryptography.) Lots of tricks to reduce the number of operations, really clever, yes somehow only using knowledge from middle school.

        We also see the correlation between the two aesthetics, since those tricks also make the worst case much faster than the naive approach.

        1. 4

          A nice post, thanks for sharing! It’s a good idea to call these approaches aesthetic choices to avoid making any unnecessary value judgements.

          It’s interesting how both approaches are optimizing the latency part of the classic Latency vs Bandwidth tradeoff. The Do Almost Nothing school ends up with more complex code since they also try to reach a bit to the bandwidth side of the equation.