1. 9
  1. 4

    I can’t help thinking GPU-rendering in a text editor is a little bit bullsh*t.

    Now that I’ve for that out of my system I immediately take it back, since the web site is pretty clear on this being a learning project, with no claims that 3D acceleration makes this editor faster/better than a regular one (as opposed to some terminal emulator projects that this makes me think of).

    1. 6

      My intuition is the opposite: text rendering is about pushing pixels on a screen, it’s kind of expected that the GPU would handle such a job. Especially considering the parallelism involved, which by the way is made even easier with fixed sized fonts.

      That being said, there’s a good chance CPU rendering would not noticeably slow things down in this case, especially with a fixed sized font where you’d have all kinds of tricks to speed things up. And there’s a thing to be said about reducing dependencies.

      If I recall correctly, the point of refterm (to take one of the most prominent example) was to show Microsoft how inefficient their own terminal is, and how much faster it could be, if only they knew about a couple dozen weird tricks game developers would very much like everyone to know —3D acceleration is only one of them.

      1. 2

        This. Even if your application does all its rendering in software and then slaps the result onto a bitmap the OS provides you, then the OS is going to use the GPU to do compositing and drawing anyway. It isn’t the 90’s anymore, pretending the GPU doesn’t exist gains you extremely little. Even the tiniest and wimpiest non-embedded system will have a display accelerator of some kind.

        …Actually, the one exception I can think of might be dedicated server CPU’s/boards, which generally need literally no user interface outside of a bios menu, lights-out menu and enough text-mode CLI to get networking set up. But I haven’t actually touched such hardware in over a decade; anyone know whether they have anything OpenGL capable built in these days?

        1. 1

          A lot of server and some high-end (such as a couple of Ryzen) CPUs still don’t have integrated graphics, so getting OpenGL on those is… Yeah.

        2. 2

          I understand the potential benefits, although in practice from what I understand 3D-accellerated terminals like Alacritty/Kitty (both of which I’ve periodically used) tend not to be not that much faster than e.g. XTerm or Gnome Terminal in benchmarks (except for for the not very useful “cat a million lines and have it scroll by” use case).

          Anyway, I feel like if it turns it is much better to show text using the GPU, it seems this should make it into the GUI toolkit, rather than each application. IIRC this is how it works with at least some text viewing components in Mac OS.

          1. 1

            I feel like if it turns it is much better to show text using the GPU, it seems this should make it into the GUI toolkit, rather than each application.

            Sure, if the system has a default GUI toolkit, it’d better provide the fastest text rendering it can provide, GPU or no GPU. I’m not sure I’m going to use it in all cases though, I’ve always been squeamish about dependencies.

            except for for the not very useful “cat a million lines and have it scroll by” use case

            It’s more useful than you think. Not cat specifically, but logs. Some programs are very log heavy, and you want the terminal to have minimum overhead while they do their work. Ideally negligible overhead, which implies being crazy fast on stress tests.

            1. 2

              I wouldn’t say it’s ever useful to have logs scroll by faster than you can read them.

              I deal with multi-GB logs on a daily basis and never have any problems like this as they are always viewed through something like less on the other side of an SSH connection.

              If somehow by accident I start something that starts overloading my connection, I can always ^C (admittedly that has some delay if on SSH, it works better with e.g. Mosh).

              1. 1

                I wouldn’t say it’s ever useful to have logs scroll by faster than you can read them.

                That’s not my point. My point is that a terminal that can render text faster than I can read it can do other things that actually interest me, such as not slowing down a program I wanted to quickly test just because that program happened to spout tons of logs I’m currently not interested in. Sure I could redirect those logs to /dev/null, but I would have to type those extra characters, and that’s if I even think of it before it’s too late.

                Another, more fundamental point: is there any good reason a terminal should ever be slow? I don’t think there is. If a single programmer can write a fast terminal in a couple weekends like Casey Muratori did, it seems to me that the extra complexity needed to get it fast, if any, is very well justified.

                In general, the faster and leaner a program is, the more generally applicable it is. For instance I would love to have my phone be my main computer. Just dock it to a work station with a keyboard and a screen, and voilà, I just turned my palmtop into a desktop. There are many reasons I don’t, but one of them is speed: my browser, IDE, compiler… would be slow. But if today’s programs were as fast as what we had 20 years ago, that approach would be very practical.

          2. 1

            In the early 2000’s (2001 or 2002) I remember a shareware terminal emulator for MacOS X whose claim to fame was that it used the 3D accelerator to render text…it was noticeably faster. Now of course everybody does it, but that was new back then.

          3. 2

            It is and it isn’t.

            Pushing a small amount of pre-rasterised monospace characters to the screen is so trivial that it shouldn’t matter, in practice there are many layers of garbage between GUI toolkit/OS APIs and running on the video game hot path lets you sidestep some of that.

            Also in practice, many terminals drop below 1FPS if you hold page down in vim, and many (all?) editors drop below 1FPS if you open 100kb of minified JSON, so GPU vs CPU rendering is a meaningless marketing bullet point.

            1. 3

              Writing to every pixel in a 3840x2160 display bitmap at 60 FPS with 4 bytes per pixel is ~1900 megabytes per second of data, which is about 10% of the total memory bandwidth of DDR4 RAM if I am looking at the right numbers. Most terminals aren’t doing that, of course, and a modern CPU can certainly push that amount of data around if it’s programmed right, but that’s not necessarily simple. IMO it’s not ever safe to assume that meeting modern expectations of graphics performance is trivial.

              1. 1

                It’d be a marketing bullet point if this was an actual product.

                However, quoting the repo’s README: “The base motivation was just simply that i wanted to have a look into OpenGL and doing GPU accelerated things, i did not plan to create a text editor from the get go. After starting to experiment a bit i decided to call this a small side Project and implement a proper editor.”

                And also some editors can deal with the “100kb minified JSON” use-case. I can tell from experience that at least Sublime Text 4 does a good job on this compared to other editors, which does actually uses marketing on being GPU-rendered since their latest major version.

              2. 1

                The biggest difference is honestly if you were to either open a big text file, have an old CPU, or a combination of both at the same time. I guess if you have a relatively recent computer, it really doesn’t matter. But for this cases, and for laptops running on battery, it could show a difference. But yeah, the author developed this as a hobby project to learn OpenGL while making a text editor bound to his likes, for the most part.

              3. 1

                Ledit will work correctly with ascii and 2 byte unicode/UTF-8, 3-4 byte unicode characters will not work.

                Seems there is some work to do before it’s actually a text editor.