Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you look into strace of something like IMGUI demo on say sdl2+opengl backend, you'll see about same syscall/sec number at 60 fps, but it'll all be sequences of writev, recvmsg, poll, clock_gettime and DRM_IOCTL_SYNCOBJ_ ioctls. Which is basically just polling for input and submitting gpu command buffers, nothing expensive, and nothing a cache can help with.


That does not really matter though: Even immediate-mode approach programs should just not be drawing new frames when the program logic says that there are no new inputs that can result in different pixels (e.g. no user inputs, animations, notifications, text content changes, etc.). One does not need to "poll" for input.


> Even immediate-mode approach programs should just not be drawing new frames

They can't not. When the backend asks for a frame you give it a frame, or the result is not defined (a black rectangle instead of window content usually).

Even if you don't redraw anything at all it's still a 2d blit from gpu memory which is two triangles, a texture and sync object. Or you need to tell the window manager what's the window content this frame by any other way which also inevitably crossess process boundaries and thus is a bunch of syscalls. Plus you need to poll for input anyway.

edit: by "poll for input" I mean the literal poll() syscall. Which is ofc the basis of async and all. How else do you get to know there was any input?


But a video game does!

You see why I think their logic that an IDE should work exactly like a video game does is not as strong as it sounds at first.

They claim browser engines just lack the raw speed to build an experience like Zed, but I know of no reason that it should be true.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: