- cross-posted to:
- zed@programming.dev
I’m still confused by this not being cross-platform. It’s made in Rust; basically every graphics library is cross platform out of the box, and so is all the file IO stuff. There will be some specialist OS api stuff in places but surely it can’t be much.
For once this comment isn’t even snark. I acknowledge my ignorance and wonder if someone could explain why the cost is bigger than I think?
Perhaps it’s setting up CI and packaging for other platforms? Maybe they want human QA on every release? Maybe the APIs for slick OS integration are more complicated than I realise? (e.g. putting UI in the taskbar)
They’re using metal which is Apple only.
But why? I saw their section about rasterising everything on the GPU, and again I find it hard to understand why they need anything more than OpenGL 3.
Their UI looks like it would be an LRU glyph cache and a sprite batcher, and then you’d have 1000fps.
You can get lower latency with vulkan then with opengl. I remember some emulators (gamecube?) talk about why they implemented vulkan.
That sounds plausible. I’m sure having the lowest possible latency was their goal. There are multiple popular rust libraries aiming to provide zero cost abstractions over a common subset of the metal, vulcan and dx12 APIs, but I’ve never actually used one.
I might be too old-school for this but this video felt like it focused on AI assisted programming and I really don’t give a damn.
@copygirl Oh man, is non-AI assisted programming old-school already? :(
Fireship often talks about big tech and AI, thats why they have a chapter on it. I dont rly give a damn either but it’s interesting to take note of
Only just got a 120Hz monitor recently, so reading scrolling text now is so much easer and faster than before. Looking forward to any IDE that can match that kind of framerate performance as well.
Too bad I don’t own a mac to be able to test out the current release of Zed as an IDE. However, I’m not sure about the growing trend of rasterizing the entire GUI, as compared to conventional text rendering methods or GUI libs with established accessibility support.
VS Code at least on my 144Hz Android phone supports High refresh rate. No idea why this is a “special feature”.
Are you using the PWA, self hosted or via code spaces/other VPS? With which web browser?
I tried hosting code server via termux for a while, but a user proot felt too slow, even if the PWA UI ran silky smooth.
Perhaps when my warranty runs out I’ll root the device to switch to using a proper chroot instead.Running as a fullscreen PWA through Brave on a Xiaomi Mi 10T, hosted on in a Linux VM. Its pretty fast for the most when doing for example Angular for the most part and the UI is butter.
I don’t know if it’s your cup of tea, but Neovide provides smooth scrolling at arbitrary refresh rates. (It’s a graphical frontend for Neovim, my IDE of choice.)
Do you use it combined with terminal emulators?
Wouldn’t that result in vertical scroll snapping to textual lines, and horizontal scroll snapping to character widths?
A personal preference I suppose for navigation, but a bit jumpy to read from while moving rapidly.the whole point is that its not in a terminal. its a gui frontend.
I was more curious about horizontal/vertical scroll snapping of text, given if the underlying vim properties are still limited to terminal style rendering of whole fractions of text lines and fixed characters, then it’s less of a concern what exactly the GUI front end is.
It scrolls smoothly, it doesn’t snap line by line. Although once the scroll animation is complete the final positions of lines and columns do end up aligned to a grid.
Neovim (as opposed to Vim) is not limited to terminal rendering. It’s designed to be a UI-agnostic backend. It happens that the default frontend runs in a terminal.
Nice! Thanks for the clarification.
It explains most of this on the features page of the site.
It’s pretty snappy even on lower spec machines. I didn’t notice any issues with scroll snapping.