[Implemented] zlib's deflate as the standard crossplatform
[Implemented] zlib's deflate as the standard crossplatform
Currently x64 uses brieflz and x86 uses jcalg1.
The interesting thing however is that zlib.lib is included with PureBasic (used by PNG etc. as well)
zlib's deflate is faster than jcalg1, and the compressed size is pretty close to jcalg1, inflate speed is pretty close to jcalg1 as well.
zlib's deflate compress better than brieflz.
zlib is the de-facto industry standard, been in use for like 10 years now,
and it still has one of the speed vs compression balances.
Fast compression and low memory use,
one of the fastest decompression speeds, and very low memory use,
compress data never increases in size, un-compressible data is simply stored,
solid code, even feeding junk into the de-compressor won't crash it.
An insane number of games and applications use and rely on it.
Webservers (Apache), PHP, etc, use or support it for compressing web pages, web browsers support it for decompressing webpages.
I'm not saying zlib's deflate should be the only compressor for PureBasic,
but it surely is perfect as the default one?
zlib.lib is around 100KB, (less when the program is compiled obviously).
If only the deflate ad inflate code is used (or stripped down to just those two) then the size is reduces to 10-15KB if I recall correctly.
No patent issues, liberal license (zlib license), multiplatform, x86 and x64, good compression, high speed, low memory use, highly supported, time tested, industry standard, can't go wrong with that can we?
Can you tell I kinda think zlib's deflate rocks?
The interesting thing however is that zlib.lib is included with PureBasic (used by PNG etc. as well)
zlib's deflate is faster than jcalg1, and the compressed size is pretty close to jcalg1, inflate speed is pretty close to jcalg1 as well.
zlib's deflate compress better than brieflz.
zlib is the de-facto industry standard, been in use for like 10 years now,
and it still has one of the speed vs compression balances.
Fast compression and low memory use,
one of the fastest decompression speeds, and very low memory use,
compress data never increases in size, un-compressible data is simply stored,
solid code, even feeding junk into the de-compressor won't crash it.
An insane number of games and applications use and rely on it.
Webservers (Apache), PHP, etc, use or support it for compressing web pages, web browsers support it for decompressing webpages.
I'm not saying zlib's deflate should be the only compressor for PureBasic,
but it surely is perfect as the default one?
zlib.lib is around 100KB, (less when the program is compiled obviously).
If only the deflate ad inflate code is used (or stripped down to just those two) then the size is reduces to 10-15KB if I recall correctly.
No patent issues, liberal license (zlib license), multiplatform, x86 and x64, good compression, high speed, low memory use, highly supported, time tested, industry standard, can't go wrong with that can we?
Can you tell I kinda think zlib's deflate rocks?
+ 1
I use zlib in most of my applications
I use zlib in most of my applications
PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
- Fluid Byte
- Addict
- Posts: 2336
- Joined: Fri Jul 21, 2006 4:41 am
- Location: Berlin, Germany
- DoubleDutch
- Addict
- Posts: 3219
- Joined: Thu Aug 07, 2003 7:01 pm
- Location: United Kingdom
- Contact:
But with the ability to decompress older files!
https://deluxepixel.com <- My Business website
https://reportcomplete.com <- School end of term reports system
https://reportcomplete.com <- School end of term reports system
- netmaestro
- PureBasic Bullfrog
- Posts: 8425
- Joined: Wed Jul 06, 2005 5:42 am
- Location: Fort Nelson, BC, Canada
netmaestro, that's a great idea!
I would also vote +1 for this request, but with your idea of a plug-in system you could use the good old commands with different compression methods. Another great advantage would be, that the current commands can be kept for future versions as well, just with tiny adjustments:
There could/should be flags when creating packages, to determine, which compression methods should be used, similar to SaveImage().
Another command could be added, informing about the compression method (zlib, jgcal1, etc.) when opening a package.
I think, Resactors arguments are convincing, since zlib seems to be used in many cases, e. g. on webservers.
Additionally, I would request to modernize the Packer-lib by introducing the ID-system. Then you could handle more than 1 package/archive at the same time.
I would also vote +1 for this request, but with your idea of a plug-in system you could use the good old commands with different compression methods. Another great advantage would be, that the current commands can be kept for future versions as well, just with tiny adjustments:
There could/should be flags when creating packages, to determine, which compression methods should be used, similar to SaveImage().
Another command could be added, informing about the compression method (zlib, jgcal1, etc.) when opening a package.
I think, Resactors arguments are convincing, since zlib seems to be used in many cases, e. g. on webservers.
Additionally, I would request to modernize the Packer-lib by introducing the ID-system. Then you could handle more than 1 package/archive at the same time.
PB 4.30
Code: Select all
onErrorGoto(?Fred)
This has been planned for quite a while, but it isn't really a priority. So better don't hold your breathnetmaestro wrote:What they might do (just guessing) is change the packing to a plugin system similar to image decoders/encoders. When all is said and done this would be the best approach imho. I hope they do it.
quidquid Latine dictum sit altum videtur
Packer support of zlib
+1
I've been badgering Fred and Freak for this for years. Its been a defacto compression standard for ages and native PB support as part of the Packer library would be a very worthwhile addition. How about if we bribed you guys to add it?!?!
I've been badgering Fred and Freak for this for years. Its been a defacto compression standard for ages and native PB support as part of the Packer library would be a very worthwhile addition. How about if we bribed you guys to add it?!?!
Hm, 4.31 and 4.40 using zlib if i am not mistaken.
The signature of the data is "zlb".
But why making the packer incompatible in the first place?
At least the x86 version could have the ZLib decompressor and detect if a compressed buffer is JCalG1 or ZLib by the signatur.
At the moment the whole packer lib is useless for me, because i need a compression thats compatible between 32bit and 64bit Windows.
The signature of the data is "zlb".
But why making the packer incompatible in the first place?
At least the x86 version could have the ZLib decompressor and detect if a compressed buffer is JCalG1 or ZLib by the signatur.
At the moment the whole packer lib is useless for me, because i need a compression thats compatible between 32bit and 64bit Windows.