1. 21
  1.  

  2. 6

    The most interesting piece there is probably the renderer: it provides an orthogonal (i.e. no dirty rectangles littering every bit of code that gets anywhere near rendering) way to do software rendering with good performance; quite impressive. It’s covered in more detail here.

    1. 2

      I also just picked rencache.c in the git repo, to look at. Seems like a very visual algorithmic approach to rendering of text:

      • Organize editing commands into a command queue (commands + cell Ids that it modifies)
      • visualize the text editing screen as grid,
      • and then for every command introspect what grid cells it modified.
      • Then redraw the cells (perhaps compressing/cancelling out commands for each cell that needed redrawing).

      It does appear to be analogous, in a way, to a virtual-dom re-renderers, only instead of a dom tree there is cell grid.

      The method of visualizing a virtual surface on which modifications are made, then introspecting a queue of functions that act on the elements of the surface, then applying some sort of compression/composing of functions to come up with an efficient ‘transformation’ function (all that some X frames per second !) – seems to be an approach that fits into a some sort of a reusable functional / template-based algorithm.

      1. 2

        analogous, in a way, to a virtual-dom re-renderers, only instead of a dom tree there is cell grid

        Can you go into more detail about this? It sounds interesting, but I don’t know enough about web development to say.

        1. 1

          Sure.

          In web browsers, the visual surface is displayed by rendering what is called sometimes ‘Render Tree’. Render Tree is a combination of a DOM (tree of HTML tags representing text/buttons/etc) and a Styles Tree. (see this post

          The above architecture is not well suited for ‘dynamic’ DOM tree manipulation. Because every time a single thing in the tree is modified, the whole thing would require redrawing.

          So developers came up with a virtual dom, that sort of ‘tracks’ the real dom. But acts as a ‘buffer of changes’ – similar to rencache.c in the posted article.

          The virtual dom accepts changes, figures out how those changes affect the real DOM and applies them in some ‘bulk’ fashion over to the real DOM. (see another post on the virtual dom topic

          Perhaps a bit of a stretch, but reading the comment in rencache.c and the corresponding explanation you linked, made me think of the above analogy.

    2. 4

      Rxi is an impressive programmer in the C/Lua scene. I’ve done some Ludum Dare game Jams along-side him, and it was impressive to see what all he made in the time he had.

      This looks like a cool editor. Now I just have to wait for someone to add Vim keybinds

      1. 1

        My thoughts exactly… and the reason I always go back to Vim (although I almost got hooked on VSCode).

      2. 3

        Lite’s implementation is one of the most beautiful I’ve seen. It’s one of those programs that you read and it’s just…elegant and beautiful.

        1. 3

          I took a look at both the Lua and C code, and it looks nice… although I prefer code with more comments. There are many files without a single comment. Even 1 or 2 well-chosen sentences at the top of the file goes a long way.

          https://github.com/rxi/lite/tree/master/data/core

          1. 2

            I mean, this whole overview kind of makes what you are asking for redundant.

            1. 1

              I’m often told that I don’t comment my code enough, so maybe that’s why I like Lite so much. :)