Added subchunking, but needs more improvements

[krestenlaust]

closes #5

[krestenlaust]

I still need to implement chunk IDs, instead of just adding delays between packages to ensure they are received in the correct order.

[krestenlaust]

The problem now is when the packets from the next image catch up with the packets from the previous image (or there is packet loss at the previous one) then the chunk IDs collide and it tries to store a chunk with the wrong size in the previous image and then it crashes.

The solutions I see are the following:

1. When a packet from a new image arrives, drop the old one as it is already out of date anyway, or there could be packet loss.
   The solution doesn't require much, but I'm afraid that frameskipping can be distracting and make the program appear laggy if it happens often.

2. When a packet from a new image arrives, replace the chunk in the old image with the new chunk so that part of the image is slightly newer.
   The disadvantage of this solution is that it requires me to change the way images are serialized, as the current one basically just takes an image file and splits it up. Because of this, the image is already compressed somewhat. The compression would disappear, and I would have to implement a new form of compression myself, and it would not be as strong as it has to compress at chunk-level instead of image-level.
   Another disadvantage is that the display of the image on the client should be updated much more often, as it should now be updated every time a packet arrives, rather than every time an entire image is assembled.

The advantage is that this method handles packet loss much better and it just updates the image continuously.

3. When a packet from a new image arrives, it is stored separately at the same time as it waits for packets from the old image, and if the new one is finished first, the old one is dropped.
   The disadvantage is the still the frameskipping, and it kinda ignores packetloss.

[krestenlaust]

Decided on going with solution 2 would be best, instead of simply delaying the issue of packetloss.

[krestenlaust]

This PR is a pain. I've been experiencing the one visual bug after the other, right now the visual is skewed when the size of the image is uneven. On top of this, I'm also experiencing problems with the removed compression, as the bandwidth required for sending full HD uncompressed even on loopback adapter requires an high amount of bandwidth: 1920 x 1080 x 3 color bytes x 8 (to convert to bits) = ~50 Megabits per frame. For 30 frames per second that's 1.5 Gbps.

I still need to find a good way to calculate the need chunks for sending a frame

[krestenlaust]

[krestenlaust]

Should be working correctly now, just need to redo some of the code and remove some comments and debug messages.