https://futureofcoding.org/ logo
Join Slack
Powered by
I woke up this morning and started implementing <P...
# devlog-together
k
I woke up this morning and started implementing Potluck for myself. I want this in my toolbox, but a browser is just not convivial enough.
potluck-annotations.webm
Stack: • Lua (12kLoC of C) • LÖVE (5MB download; depends on a minimal graphics stack) • LoveFrames (25kLoC of Lua for a GUI toolkit) • a text editor (5kLoC of Lua) • 500 LoC of live programming infrastructure Properties of this stack: • minimal dependencies • cross-platform; runs on Windows • easy for anyone to modify •

live; modify without restarting▾

k
I really like how you are exploring the space of minimal dependencies while remaining practically usable in today's computing environment.
k
Ok, I may have under-estimated how much work Potluck will be. To build Potluck I need the ability to render tables, and to render tables that I can type into I really need a DOM. Prev-gen GUI toolkits like LoveFrames won't cut it; I need the ability to dynamically adjust dimensions as contents change. Hence this detour. The good news: I don't need much. The format is just literal Lua table syntax. Each node (div) contains either text, a row of nodes, or a column of nodes. Other supported attributes: 
fg
, 
bg
colors and 
margin
that acts like 
margin-top
or 
margin-left
depending on whether the parent has rows or columns.
j
One very nice trick from the scheme community is the "tag is really just the name of a function" approach taken by Scribble, Pollen, et al.
k
Interesting! In particular: "This is a nightmare if you imagine this turning into some sort of long-lived standard with versions and compatibility guarantees. I don't. I just want an app-internal format for creating UIs with very little code." Craft rather than industrial design. I'd love to see more experiments in this space! I see my own Leibniz projects there as well, though for a much more specialized application domain. This now makes me wonder if I should try to go for "full craft", i.e. provide Leibniz export in craft-friendly data formats rather than industry-standard ones (XML etc.).
k
It's an interesting lens. Do you see any drawbacks to the industry-standard approach for your projects? I'm wondering if there are drawbacks you've always been aware of, but you're starting to weight them differently.
k
The drawbacks of industry standards are often (1) a steep learning curve and (2) too much rigidity. Consider XML. Even with XML libraries available for all major programming languages, extracting data from a particular XML schema is a lot of work, and modifying the schema for an experimental extension is even worse.
On the other hand, when archiving data I definitely do want to follow industry standards.So it's not a question of choosing the better option, but of supporting both.
k
This was surprisingly hard: making the animation smoother by drawing to a texture just once. I learned two things: • Just how slow LÖVE is. On my 1.4GHz (/core) laptop (running Linux) an empty app (just initializing graphics every frame) runs at barely 60fps (15ms/frame). It's very easy to overflow even 30fps. • I don't know if my standards are too high, but the way LÖVE does texture mapping is a little weird: https://codeberg.org/akkartik/driver.love/commit/207ebfae36902cb18a1d2fcf5e31e6301ad5a2e0
codemap-canvas.webm
n
I looked into it a bit because I felt like those performance numbers sounded suspicious. Looks like there is (or was, 14+ years ago 😶 ) a driver-level bug with vsync: https://love2d.org/forums/viewtopic.php?t=116 Maybe the bug is actually in the mechanism LÖVE uses to enable vsync, but either way, I am pretty convinced that disabling vsync should solve your performance problems
k
Doesn't disabling vsync have its own risks and caveats? I don't really know what I'm doing there..
n
The only I can think of is tearing, which is annoying at worst, and shouldn’t be an issue unless your render code is actually the bottleneck. Okay, and maybe some timing stuff if you were using frame numbers instead of wall clock. Caveat: I’m not a graphics person by trade, but I did take some computer graphics classes and am a bit of a gaming nerd 🙃
k
Definitely sounds worth a try. Thanks!
I just tried it and yes, the empty app went from 15ms/frame to 0.005ms/frame without vsync! It's a little different from your link in that my CPU doesn't get pegged with vsync. But it does introduce a non-busy wait. Unfortunately this doesn't affect my app's initial animation. If I bump back to before my recent texture-mapping changes and try it with/without vsync, I see no perceptible difference. I might have been able to find an alternative way to speed up the animation, though, if I'd disabled vsync.. I'm going to disable vsync going forward. It seems clear that any drawback stemming from this decision is going to be very obvious, so no reason not to try it.
n
Hm. If it wasn’t busy-waiting, and you didn’t see improvement on your actual workload, then it sounds like vsync wasn’t actually causing your problem. Put another way, to run your app at 60fps, something must take 15ms, and if you’re not doing any actual work, the draw function will be that something. But yeah, it’s likely that turning vsync off won’t hurt either 🙂
k
One bit of follow-up: it turns out that disabling vsync increases CPU utilization quite dramatically, from 2-3% to 20% for an empty app. Non-empty apps increase even more. I noticed this when my laptop's fan started coming on; something that has seldom happened. My mental model now is that without vsync LÖVE just cranks through frames as quickly as possible. It won't make a difference if there's lots to do between frames, but 0 work will lead to infinite fps, approximately. (Obviously, I'd love to hear if this logic seems flawed.)
w
That reminds me... of that one time... in StarCraft II some scene on Raynor's spaceship with an especially low polycount fried one of my MacBooks.
k
My environment now has tests. In this 1-minute animation you can see me make a change that breaks some tests. The edges of my vision go red. I zoom out to see what broke. I can click on places on the map to zoom in, Exposé-like, on failing tests. https://git.sr.ht/~akkartik/driver.love
freewheeling-tests.webm
Open in Slack
PreviousNext
Powered by