top | item 46409359

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

190 points| andros | 2 months ago |en.andros.dev

53 comments

order

kvakvs|2 months ago

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 column and they will be textured shaded and scaled by the browser?

ffsm8|2 months ago

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

Jare|2 months ago

IIRC someone did exactly that around 15 years ago, a game renderer using div strips, first with Wolfenstein and then Doom. It may have been "Jacob Seidelin" who was very active experimenting with early HTML5 tech, but I've lost all links or they've vanished from the web - I only keep two screenshots I used in a lecture back then.

oersted|2 months ago

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.

dentalnanobot|2 months ago

Wonder if it would be more efficient to use a single-pixel column and then draw the colours with gradient stops?

rockyj|2 months ago

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

andros|2 months ago

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.

andypants|2 months ago

This is more like HTMX+websockets than phoenix liveview.

  - It's not stateful
  - There's no html diffing
  - Handlers return target+fragment instead of updating state

andros|2 months ago

Each user has their ID in the backend; you can save their status... if you want.

scop|2 months ago

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.

andros|2 months ago

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.

crimsonnoodle58|2 months ago

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 come from WebSockets, and maybe skipping some Django middleware. Anyone care to elaborate?

aeonfox|2 months ago

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.

ksec|2 months ago

In the blog post it uses "600,000 divs/second!" and "10,000 divs using its template engine" while the heading uses 600.000.

I assume the difference in usage of full stop / period or comma is accidental?

andros|2 months ago

Yes, you right hehe. I had fixed!

hoistbypetard|2 months ago

That is beautifully ridiculous! Thank you for doing that and sharing.

andros|2 months ago

Thank you for this comment :)

lukevp|2 months ago

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?

agentifysh|2 months ago

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

evilmonkey19|2 months ago

I wish we could host Django apps with the tasks and everything on Cloudflare workers. Also it would be nice to have a DB like SQLite within Cloudflare.

isodev|2 months ago

Bunny has very solid edge runtime if you manage to squeeze it into wasm or “magic containers” so it’s just a pod

https://bunny.net/cdn-lp

leobuskin|2 months ago

you can do it on wasmer's workers, their last wasm/python approach is pretty solid (compatibility, performance). it's sad to say, but after 4 years of "beta" Python support on CF workers - it's still ugly. I dunno who was responsible for such a neglect, but even with the last changes - total fiasco

_boffin_|2 months ago

We ran Django on AWS Lambas years ago. Wasn’t fun and caused headaches, but worked

pawelduda|2 months ago

Shame Phoenix LiveView is missing from the comparison

leobuskin|2 months ago

It's only django-related third-party packages comparison (and SSR itself), would be a bit strange to compare with a different language/stack and/or framework

tomcam|2 months ago

Doesn't this also show that HTML/CSS performance is incredibly good on web browsers these days?

elzbardico|2 months ago

This shows how modern hardware is ridiculously powerful.

pallar|2 months ago

> 600.000 divs/segundo

Basado

jkhall81|2 months ago

When will people stop doing this and just leave Doom alone?