GPU accelerated vector graphics rendering is an open problem.
Unfortunately, even if you have very fast drawing, there are plenty of other ways to make software slow. But high performance GUI software is the main thing I'm working on at the moment and I expect to have interesting results in the coming months. If nothing else, it should be a data point of how fast GUI software can be.
Unfortunately it's not this simple. Unicode and multilingual support means you can't possibly generate a single bitmap to contain all possible characters. Modern UIs (including text editors and terminals) generally support various zoom levels, which requires re-rasterizing glyphs at different zoom levels. This means you typically have to rasterize vector graphics (your font) on the fly as needed and then update your bitmap.
Edit: Also, emojis and certain scripts require composting multiple glyphs together. This means you have to figure out which glyphs are required for your codepoint and use your font metrics to composite the glyphs appropriately. Then throw in mathematical notation and all bets are off.
My point is, rendering text is not a simple done deal, but it's also not an impossible feat and it can be done efficiently.
vector graphics are not rendered directly to the screen. fonts are rasterized first, then the rasterization is what the GPU receives.
lmao welcome to HN, if you don't enjoy that experience I don't recommend you try to argue here.
What difference does it make if you're caching the rasterization or not? You're still rendering vector graphics. And you're not just rasterizing once.
Modern font renderers can't get away with rasterizing glyphs once and reusing them anymore than arbitrary vector graphics renderers can. I sure hope my vector graphics editors cache the rasterizations instead of re-rasterizing needlessly.
it's not every frame. that's my point. that you missed twice because you can't see past details to the point of the statement.
> figure out which glyphs are required for your codepoint and use your font metrics to composite the glyphs appropriately.
this is all done in shaping though, the renderers just see "put this thing there" and (at least in GTK) we just maintain texture atlases that are updated on the fly.
you're correct that it doesn't solve the same glyph at lots of scales though. but glyphy does (and at high FPS too).
To be clear, I'm not bashing on GTK. I'm saying that it definitely isn't as simple as the above comment implies ;)
the bitmap stuff still has major drawbacks though, like maintaining grid alignments and pixel boundaries where as this stuff (mostly) goes away using glyphy.
still work to be done around hinting though (hence not merged).
Also, on Windows, the "acrylic" thing is a circus show. Every app behaves differently. It also manages to sometimes lag on an RX5600. I know it's an "old" gpu, but still...
But in most contexts, it is not necessary to render vector graphics 'live'; caching is acceptable, so this should not be a bottleneck for most desktop software.
Bitmaps are much faster to draw and can be made pixel-precise up front. With vectors it's easy to have pixel cracks or blurry lines because it's offset .5px.
yes, but that alone doesn't require that bitmap graphics be used.
> With vectors it's easy to have pixel cracks or blurry lines because it's offset .5px.
only if your renderer or your artwork isn't done correctly; inkscape used to be notorious for floating point rounding errors showing up with very few manipulations of a shape.
it's also been very easy to very quickly rasterize vector graphics for some time. maybe not fast enough in the past I guess, but computers are certainly fast enough now.
I look forward to a time when UIs are just all vector all the time, and it's the monitor itself which rasterizes, thanks to a program that the attached device uploads as it boots up or as the monitor is connected.
it's going to get more and more difficult to continue increasing display resolutions and refresh rates over long inexpensive cables if we continue to rasterize on a computer and push raw pixels to the display device.
Sure there has been, in the form of the nvidia path rendering extension. https://developer.nvidia.com/nv-path-rendering
It works great, on nvidia cards. Adobe Illustrator on Windows makes good use of it. Calling the extension from C/C++ and Python is no big deal.