Browse Source

document ideas, add readme img

Norwin Roosen 3 months ago
parent
commit
5b75c2a19e
3 changed files with 47 additions and 1 deletions
  1. 44
    0
      IDEAS.md
  2. 3
    1
      README.md
  3. BIN
      benchmarks/hochwasser_shuffle_vs_ordered.gif

+ 44
- 0
IDEAS.md View File

@@ -0,0 +1,44 @@
1
+# feature ideas
2
+- pluggable cli: commands for image, text, shader rendering
3
+- support animations / frame concept
4
+- visualization client
5
+- CnC: server distributes jobs to connected clients
6
+- webassembly port?
7
+
8
+# performance considerations
9
+- server limitations: rendering is bottleneck. maybe artificial limitations (commands per draw, connections per IP, queue)
10
+  - when network isn't bottleneck: fetch each pixel & only send updates for wrong color (?)
11
+  - sync sending with draw frequency (?)
12
+  - use virtual subnets for more IPs (ipv6?) (?)
13
+- client limitations: PCI bus is bottleneck? depends on HW I guess
14
+  - precompute everything
15
+  - distribute across cores for max PCI bus saturation (?)
16
+- network limitations: packet size, ACKs, congestion
17
+  - treat benchmarks on `loopback` with care, it has no packet size limitation. real world interfaces will enforce a max size of 1514 bytes [1]
18
+  - avoid packet split if >1514B (?)
19
+  - use `TCP_NODELAY` (?)
20
+  - https://stackoverflow.com/questions/5832308/linux-loopback-performance-with-tcp-nodelay-enabled
21
+- cognitive limitations: draw order
22
+  - randomized pixel order should give a better idea of the image with equal dominance (?)
23
+
24
+# concept: CLI for distributed hochwasser v2
25
+
26
+> pixelflut endlich *durchgespielt*
27
+
28
+```
29
+hochwasser     --server
30
+    provide    [type] [input] --effect --offset --scale --port --nosend
31
+    subscribe  --connections --shuffle --diffmode
32
+    view       --fullscreen
33
+```
34
+
35
+- CLI via `github.com/spf13/cobra`
36
+  - `--server` refers to pixelflut server or hochwasser jobprovider, depending on mode
37
+
38
+- jobprovider has different input types (`image`, `text`, `shader`?), each is parsed into an `image.GIF`
39
+  - jobprovider also sends image itself?
40
+
41
+- when subscriber connects to jobprovider, `GIF` is split up, and (re)distributed to all subscribers
42
+  - protocol: (address,offset,imgdata) serialized with `gob`?
43
+
44
+- viewer fetches into framebuffer, renders via opengl?

+ 3
- 1
README.md View File

@@ -1,4 +1,6 @@
1
-# 🌊🌊🌊 Hochwasser 🌊🤽🌊
1
+<h1 align="center" >🌊🌊🌊 Hochwasser 🌊🤽🌊</h1>
2
+<p align="center"><img src="benchmarks/hochwasser_shuffle_vs_ordered.gif"/></p>
3
+
2 4
 Highly efficient client for [Pixelflut]:
3 5
 Faster than [sturmflut]!
4 6
 

BIN
benchmarks/hochwasser_shuffle_vs_ordered.gif View File


Loading…
Cancel
Save