dd optimisation

[davidaspden]

Is it possible to be more selective with dd or write a c utility that samples the framebuffer better to get the speed up we need. Seems going via gp compression has already proved how much gain is to be had but we undo the good at the other end.

The framebuffer should be structured enough to let us be more intelligent.

Been so long since I did any C coding I may have to hello world and try this.

[rien]

What do you mean with 'sampling the framebuffer'? Do you want to make the compression lossy? Or throw away the unneeded color information?

[davidaspden]

I pulled the framebuffer to a file last night and played with dd trying to selectively grab parts of the file. with a bs of 1 it took about 8 seconds to grab the file so my idea for using seek and skip won't work. Currently it is grabbed in one go i can see, and with the code i got a 5mb image. Photoshop can open if you help it out and it is indeed the screen.
But yeah, throw away the colour information was my late night idea!

[rien]

We also read the first 1408 * 1872 * 2 bytes (width * height * 2 byte per pixel), there are a lot null bytes after that.

You could try researching the difference between the two color schemes (grey16le and rgb565le). If we can just throw away every other byte for example that would be great!

I'm a bit hesitant in writing custom binaries for this because that would complicate the setup further.

[davidaspden]

I'm with you on the binaries.

I also, when not specifying certain parameters, got what looked like a blank screen worth of null bytes.

I'm thinking le is lower endian? so we have 16 bits to encode the grayscale. I was thinking could we not drop some info here, 1bit monochromatic. We could still pop it through gzip afterwards, though as the page builds up we would have diminishing returns on that.

[rien]

Please go ahead and experiment with this. There is already an issue (#14) where we are discussing possible improvements, so please join us there with your findings.