document ideas, add readme img
This commit is contained in:
parent
6e15e7518b
commit
5b75c2a19e
|
@ -0,0 +1,44 @@
|
||||||
|
# feature ideas
|
||||||
|
- pluggable cli: commands for image, text, shader rendering
|
||||||
|
- support animations / frame concept
|
||||||
|
- visualization client
|
||||||
|
- CnC: server distributes jobs to connected clients
|
||||||
|
- webassembly port?
|
||||||
|
|
||||||
|
# performance considerations
|
||||||
|
- server limitations: rendering is bottleneck. maybe artificial limitations (commands per draw, connections per IP, queue)
|
||||||
|
- when network isn't bottleneck: fetch each pixel & only send updates for wrong color (?)
|
||||||
|
- sync sending with draw frequency (?)
|
||||||
|
- use virtual subnets for more IPs (ipv6?) (?)
|
||||||
|
- client limitations: PCI bus is bottleneck? depends on HW I guess
|
||||||
|
- precompute everything
|
||||||
|
- distribute across cores for max PCI bus saturation (?)
|
||||||
|
- network limitations: packet size, ACKs, congestion
|
||||||
|
- treat benchmarks on `loopback` with care, it has no packet size limitation. real world interfaces will enforce a max size of 1514 bytes [1]
|
||||||
|
- avoid packet split if >1514B (?)
|
||||||
|
- use `TCP_NODELAY` (?)
|
||||||
|
- https://stackoverflow.com/questions/5832308/linux-loopback-performance-with-tcp-nodelay-enabled
|
||||||
|
- cognitive limitations: draw order
|
||||||
|
- randomized pixel order should give a better idea of the image with equal dominance (?)
|
||||||
|
|
||||||
|
# concept: CLI for distributed hochwasser v2
|
||||||
|
|
||||||
|
> pixelflut endlich *durchgespielt*
|
||||||
|
|
||||||
|
```
|
||||||
|
hochwasser --server
|
||||||
|
provide [type] [input] --effect --offset --scale --port --nosend
|
||||||
|
subscribe --connections --shuffle --diffmode
|
||||||
|
view --fullscreen
|
||||||
|
```
|
||||||
|
|
||||||
|
- CLI via `github.com/spf13/cobra`
|
||||||
|
- `--server` refers to pixelflut server or hochwasser jobprovider, depending on mode
|
||||||
|
|
||||||
|
- jobprovider has different input types (`image`, `text`, `shader`?), each is parsed into an `image.GIF`
|
||||||
|
- jobprovider also sends image itself?
|
||||||
|
|
||||||
|
- when subscriber connects to jobprovider, `GIF` is split up, and (re)distributed to all subscribers
|
||||||
|
- protocol: (address,offset,imgdata) serialized with `gob`?
|
||||||
|
|
||||||
|
- viewer fetches into framebuffer, renders via opengl?
|
|
@ -1,4 +1,6 @@
|
||||||
# 🌊🌊🌊 Hochwasser 🌊🤽🌊
|
<h1 align="center" >🌊🌊🌊 Hochwasser 🌊🤽🌊</h1>
|
||||||
|
<p align="center"><img src="benchmarks/hochwasser_shuffle_vs_ordered.gif"/></p>
|
||||||
|
|
||||||
Highly efficient client for [Pixelflut]:
|
Highly efficient client for [Pixelflut]:
|
||||||
Faster than [sturmflut]!
|
Faster than [sturmflut]!
|
||||||
|
|
||||||
|
|
Binary file not shown.
After Width: | Height: | Size: 452 KiB |
Loading…
Reference in New Issue