search

BurntSushi / xgbutil

A utility library to make use of the X Go Binding easier. (Implements EWMH and ICCCM specs, key binding support, etc.)
Do What The F*ck You Want To Public License
194 stars 46 forks source link

png files (gopher subpackage) double-gzip'd #1

Closed extemporalgenome closed 12 years ago

extemporalgenome commented 12 years ago

The png format already uses zlib internally for compression -- compressing it again is very unlikely to provide additional compression, and requires additional processing (once for your decompression, another time for the image library to decompress the png's pixels).

Large byte slices may also cause pathological behavior in the gc compiler (memory use ballooning). https://github.com/jteeuwen/go-bindata specializes in making sure the given binary file is compiled into a readonly memory segment without the major adverse effects -- though again, gzipping png files is best avoided.

BurntSushi commented 12 years ago

Ah, I did not know go-bindata had added an option to not compress data. (Haven't go get'd it in a while.)

I tried this out with the gopher image, and image/png.Decode is giving me an unexpected EOF error. When I go back to go-bindata with compression, things work. I'm going to do a bit more digging before I report this to go-bindata.

Large byte slices may also cause pathological behavior in the gc compiler (memory use ballooning). https://github.com/jteeuwen/go-bindata specializes in making sure the given binary file is compiled into a readonly memory segment without the major adverse effects -- though again, gzipping png files is best avoided.

Duly noted. This isn't a problem with the gopher package, since it's a toy only used in the examples. However, I'll keep an eye out for this in Wingo, where I'm using embedded binary data for fonts and images when nothing else is available.

Thanks! :-)

BurntSushi commented 12 years ago

I've removed embedded resources from Wingo since it ended up behaving exactly as you said it might: memory use ballooned during compilation. (Around ~2GB.)

As such, I'm closing this. Whether the gopher image is embedded properly is of no consequence to me here. It's small and only used in the examples.