update ideas & readme

IDEAS.md

@@ -1,11 +1,16 @@
 # feature ideas
-- pluggable cli: commands for image, text, shader rendering
+- more draw modes
+  - patterns
+    - https://github.com/MarcelMue/konstrukt ?
+  - image scaling
+  - snake
+  - sheep.exe
+  - offset rand: random size/color
+- proper public api for the fast network handling
+  - `Fluter` abstraction, implementing `Reader` to update commands? ringbuffer?
 - support animations / frame concept
-- visualization client
+- support (stackable) effects
-- CnC: server distributes jobs to connected clients
+- make job distribution fully P2P using [2D CAN / Z-ordercurve adressing](https://git.nroo.de/norwin/geo-dht)
-  - or fully P2P using [2D CAN / Z-ordercurve adressing](https://github.com/noerw/geo-dht) (p2p implementation needed)
-- 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)
@@ -13,8 +18,8 @@
   - 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 (?)
+  - use userland tcp stack (e.g. https://github.com/google/netstack or even https://github.com/luigirizzo/netmap)
 - 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 (?)
@@ -22,25 +27,4 @@
   - 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 (?)
-
+  - use an energy function like in seam carving to prioritize regions?
-# 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?

README.md

@@ -2,13 +2,9 @@
 <p align="center"><img src="benchmarks/hochwasser_shuffle_vs_ordered.gif"/></p>
 <p align="center"><img src="benchmarks/nmzs.gif"/></p>
 
-Highly efficient, distributed [Pixelflut] client.
+Highly efficient distributed [Pixelflut] client.
 
-> Hochwasser brings back the */fun/* in social DDoSing!
+- Sends static images, text, generated patterns (animations upcoming)
->
-> No more micro-ddosing: Get Hochwasser now and experience highs never seen before!111!
-
-- Can send static images, text, generated patterns (animations upcoming)
 - REPL enables fast iterations
 - CnC server + client architecture (it's webscale!) (can also run in a single process)
 - Faster than [sturmflut] (in some benchmarks at least)
@@ -17,11 +13,32 @@ Highly efficient, distributed [Pixelflut] client.
 [pixelflut]: https://cccgoe.de/wiki/Pixelflut
 [sturmflut]: https://github.com/TobleMiner/sturmflut
 
+### testimonials
+> Pixelflut endlich *durchgespielt*.
+>
+>   - Steffen Cybert
+
+> N-no more micro-ddosing: bring on ssome Hochwasser and exppperience colors never seen befffore!1!
+>
+>   - Morty
+
+> Hochwasser brings back the D in *social DDoSing*! Man, I forgot which one..
+>
+>   - Doc Brown
+
 ## build / install
 1. have a `go` installation >= 1.12
 2. `go get github.com/SpeckiJ/Hochwasser`
 3. `go install github.com/SpeckiJ/Hochwasser`
 
+> The help texts may be lacking, it's recommended to read `rpc/repl.go`.
+
+## hacking
+Look at the `github.com/SpeckiJ/Hochwasser/pixelflut` subpackage, it contains the performance sensitive core.
+
+The code is getting somewhat ~~bloated~~enterprise-ready, so if you want to quickly render a fun thing,
+it may be easier to just build a separate executable on top of `pixelflut.Flut()`, than to extend Hochwasser.
+
 ## benchmark
 The following benchmark was run on a max-spec X280 against version [d4c574b].
 
@@ -52,6 +69,6 @@ go run main.go -image benchmark/test.png -connections 10
 [iperf]: https://iperf.fr/
 
 ## future ideas
-For future ideas check [IDEAS](https://github.com/SpeckiJ/Hochwasser/blob/master/IDEAS.md)
+see [IDEAS](https://github.com/SpeckiJ/Hochwasser/blob/master/IDEAS.md).
 
 <p align="center"><img src="benchmarks/hochwasser_vs_sturmflut.gif"/></p>