# 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? - use userland tcp stack (e.g. https://github.com/google/netstack or even https://github.com/luigirizzo/netmap) # 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?