defnull/pixelflut

apparently, there's also a C implementation

ccoenen opened this issue · 7 comments

I found this, but I haven't tested it yet: https://github.com/ands/pixel

I have seen that a while ago but unfortunately the "YOLO License" is useless and does not allow anything to anyone, so effectively the linked repository is not open source and cannot be used without breaking copyright laws.

So, the last two days I wrote my own C server (based on OpenGL/GLFW and libevent). It's in the 'feature-pixelnuke' branch. I suck at C, but it works on my computer ;) Ayn help would be appreciated.

I am not any good ad C myself, But I have a Raspberry Pi right here that's mostly used for "HEY LET'S HAVE A PIXELFLUT PARTY". In other words: I can be your beta tester. I'm schaduling a Pixelflut thing for late april anyway, might as well use the C version

I'm not sure if this compiles or runs on a RasPI or what is needed to get it to compile. Would be a valuable target, though.

Also interesting: is python actually its bottleneck right now? The performance with ~20 people was not breathtaking. But this could also be the ("old") Pi 3's wonky network interface. I'll have to try this on a 3+, which is supposed to have slightly better/faster ethernet.

In Python the string handling is the bottleneck. Network traffic is split into lines, converted to string, stripped, splitted, parsed, and more. That causes a lot of intermediate string objects to be created. Parsing the byte data directly would improve the performance significantly.

On the other hand, the Python version is designed to be easily hackable and 'fair'. For example, there is a sleep call every 10 lines to limit the lines-per-second per client. Removing that would increase throughput a lot, but would also allow fast clients to draw hundreds of pixels at once, which might look less fluent on screen.

If pure throughput is your priority, there is sure a lot of room to improve the python implementation.

Really nice to hear that "Pixelflut parties" are a thing, though :)

We'll track Raspberry Pi compatibility in #8