It definitely isn’t running at 60 fps in the video. Is this css performance or something? Or this not really running as fast as it’s stated?
Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
31–40 of 55 posts
Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
#32Very impressive! Worth noting that HTMX also has a WebSocket extension - https://v1.htmx.org/extensions/web-sockets/ so one could potentially also do "live views" in more performant runtimes like JVM or Node.js
My first version of Django LiveView used HTMX. WebSocket connectivity is one aspect; there is another part of logic and architecture where it falls short.
Can you tell us more? Espacially, how does they both fair with auth.
Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
#33Since Doom renders the image with vertical columns of pixels (floor, lower wall, portal if exists continues rendering the other sector, then upper wall then ceiling) and since browsers are very good at drawing the sprites out of larger textures... You could send vertical divs shaded with the sector light level and picking the correct textures. Instead of hundreds per column you will have like 5 divs on average per co…
At that point just run the browser on the server and use proper cloud gaming tech to stream the screen and have low-latency interactivity.
If it's streaming at 60 fps, the bottleneck is in the browser, which is doing what it can :)
Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
#34Earlier quoted context omitted.
My first version of Django LiveView used HTMX. WebSocket connectivity is one aspect; there is another part of logic and architecture where it falls short.
Can you tell us more? Espacially, how does they both fair with auth.
There is native middleware in Channels. I have it documented with a brief example in the documentation, and I also mention some security measures.
Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
#35Earlier quoted context omitted.
I assume Django LiveView is directly inspired by Phoenix LiveView. It's essentially diffing template expansion on the backend and sending patches to the frontend via websockets where JS then applies the patches. Clicks and other interactions are also transmitted to the backend where state for the socket is updated and the template is reevaluated, hence completing the loop.
The concept is correct, but it's a bit simpler Its architecture is explained in the documentation, that's why it's so fast!
I looked(admittedly briefly) and couldn't find the architecture explanation in the docs here: https://django-liveview.andros.dev/docs/
Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
#36This shows how modern hardware is ridiculously powerful.
Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
#37Tangential question: is it common for frameworks to use the same name as a package from another framework? I had never heard of Django LiveView, but have used Phoenix’s Liveview and assumed that’s what it was. Not sure if I like that? I.e. does it imply some sort of endorsement or partnership? I do like that Laravel went with Livewire to distinguish it.
There are two things I'm really bad at: invalidating the cache and naming frameworks. It has that name because it's very inspired. It's an adaptation of Django.
And well done! I really prefer very descriptive names, even at the expense of originality than some ridiculous invention like "Nano Banana".
Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
#38That is beautifully ridiculous! Thank you for doing that and sharing.
Thank you for this comment :)
Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
#39Earlier quoted context omitted.
The concept is correct, but it's a bit simpler Its architecture is explained in the documentation, that's why it's so fast!
I looked(admittedly briefly) and couldn't find the architecture explanation in the docs here: https://django-liveview.andros.dev/docs/
I apologize, I assumed the architecture would be understandable from the examples. I'll keep that in mind!
Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo
#40Earlier quoted context omitted.
There are two things I'm really bad at: invalidating the cache and naming frameworks. It has that name because it's very inspired. It's an adaptation of Django.
And well done! I really prefer very descriptive names, even at the expense of originality than some ridiculous invention like "Nano Banana".
IIUC the "Nano Banana" name was originally used on LMArena when the model had not yet been announced; the purpose of the name was therefore to be as opaque as possible. I assume they hadn't originally intended to keep using it after the announcement, but it unexpectedly took off among users.