Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

en.andros.dev

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#21

Post by andros »

aeonfox wrote: post #16
crimsonnoodle58 wrote: post #15

So SSR is 50ms and LiveView is 10ms, what test was being performed to achieve these timings? Rendering a sample page or rendering doom? Also LiveView is described as "Build rich, dynamic user experiences with server-rendered HTML without writing a single line of JavaScript." and their example uses django templating to render the HTML that is returned. So what are we really measuring here? The speed up seems to solely…

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!

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#22

Post by scop »

Tangential 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.

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#24

Post by andros »

jasonjmcghee wrote: post #17
ffsm8 wrote: post #14

Earlier quoted context omitted.

I believe he stated in the beginning pretty clearly that the point of this exercise was to stress test the Liveview performance. Making this more efficient would be kinda counter productive

I agree, but it certainly wasn't performant (in the video). I'd be curious to see what parameters are required for a smooth / playable demo. Or am I missing something? (Slow input with no interpolation?)

To improve fluidity, all you have to do is change the frames per second or the resolution, although the goal is not to make it playable. :D

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#25

Post by andros »

rockyj wrote: post #10

Very 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.

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#26

Post by oersted »

kvakvs wrote: post #8

Since 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.

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#27

Post by andros »

scop wrote: post #22

Tangential 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.

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#28

Post by andros »

ffsm8 wrote: post #14
kvakvs wrote: post #8

Since 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…

I believe he stated in the beginning pretty clearly that the point of this exercise was to stress test the Liveview performance. Making this more efficient would be kinda counter productive

That is!

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#30

Post by fulafel »

agentifysh wrote: post #4

if only i could run django on cloudflare workers guess i could run it on a dedicated server would be nice if we can get django and liveview working without a server

They just announced many improvements to Python workers earlier this month: https://blog.cloudflare.com/python-workers-advancements/

https://github.com/G4brym/django-cf has a template (among other things) to get started

Another option is the containers stuff mentioned in sibling comment but it's not so FaaS.

Post reply on HN