31–40 of 134 posts
This is the first GUI app I've seen built with WebGPU. This is pretty interesting, could this be the future of cross platform GUI frameworks?
AFAIK wezterm[1] and warp[2] are built on top of the WebGPU [1] https://wezfurlong.org/wezterm/ [2] https://www.warp.dev
My question is what's their selling point, I used the past few years few terminals that have pretty good features: - Alacritty minimal and blazingly fast - Wezterm with batteries included - Warp even batteries included
Kitty has the lowest latency and is the best terminal in the market, but they are not on windows.
Earlier quoted context omitted.
Rendering text is surprisingly resource-intensive. 10 years ago I was tasked with making a mobile browser game and the thing that took 30% of the time when rendering a frame were the few bits of text that were there to display the score etc. Once we started heavily caching text, performance increased considerably.
Isn't rendering text inside a graphics framework and then saying that rendering text is surprisingly resource-intensive a bit like implementing an O(n log n) algorithm with nested for-loops and saying that the problem domain is surprisingly resource-intensive? Surely the thing that was causing text rendering to be resource-intensive was doing it inside a graphics framework?
If you don't rotate or zoom, then most of the work can be cached (at least when using latin fonts with few ligatures) which make things appear to be fast, but if you tried to render text in real time without caching (because you're allowing rotation and zoom, and you can't cache everything) then you'd see how expensive it is.
Couldn't you just use Rust + OpenGL/SDL2/.. or even AppKit if macOS is the only supported OS?
My question is what's their selling point, I used the past few years few terminals that have pretty good features: - Alacritty minimal and blazingly fast - Wezterm with batteries included - Warp even batteries included
Earlier quoted context omitted.
Rendering text is surprisingly resource-intensive. 10 years ago I was tasked with making a mobile browser game and the thing that took 30% of the time when rendering a frame were the few bits of text that were there to display the score etc. Once we started heavily caching text, performance increased considerably.
Isn't rendering text inside a graphics framework and then saying that rendering text is surprisingly resource-intensive a bit like implementing an O(n log n) algorithm with nested for-loops and saying that the problem domain is surprisingly resource-intensive? Surely the thing that was causing text rendering to be resource-intensive was doing it inside a graphics framework?
I have news for whoever did that screen shot: 256 colours is not "all colours" nowadays. (-: There was a real push, which must be approaching a decade ago at this point, to get all terminal emulators able to understand the ITU-T T.416 control sequences for direct 24-bit RGB colour. Even if they implement it really badly , and some do, almost everyone tries to support this colour system now. See the screenshot of the…
I have news for whoever did that screen shot: 256 colours is not "all colours" nowadays. (-: There was a real push, which must be approaching a decade ago at this point, to get all terminal emulators able to understand the ITU-T T.416 control sequences for direct 24-bit RGB colour. Even if they implement it really badly , and some do, almost everyone tries to support this colour system now. See the screenshot of the…
I still stubbornly use it as my daily driver for some probably terrible reason.