[Implemented] zlib's deflate as the standard crossplatform

Got an idea for enhancing PureBasic? New command(s) you'd like to see?
User avatar
Rescator
Addict
Addict
Posts: 1769
Joined: Sat Feb 19, 2005 5:05 pm
Location: Norway

[Implemented] zlib's deflate as the standard crossplatform

Post by Rescator »

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? :P
User avatar
ts-soft
Always Here
Always Here
Posts: 5758
Joined: Thu Jun 24, 2004 2:44 pm
Location: Berlin - Germany

Post by ts-soft »

+ 1

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.
Image
srod
PureBasic Expert
PureBasic Expert
Posts: 10589
Joined: Wed Oct 29, 2003 4:35 pm
Location: Beyond the pale...

Post by srod »

Yes being able to use the same algorithm with PB x86 and PB x64 would be great. Though I think Fred said that this is indeed forthcoming.

+1.

:)
I may look like a mule, but I'm not a complete ass.
User avatar
Fluid Byte
Addict
Addict
Posts: 2336
Joined: Fri Jul 21, 2006 4:41 am
Location: Berlin, Germany

Post by Fluid Byte »

+1
Windows 10 Pro, 64-Bit / Whose Hoff is it anyway?
User avatar
DoubleDutch
Addict
Addict
Posts: 3206
Joined: Thu Aug 07, 2003 7:01 pm
Location: United Kingdom
Contact:

Post by DoubleDutch »

But with the ability to decompress older files!
https://deluxepixel.com <- My Business website
https://reportcomplete.com <- School end of term reports system
User avatar
netmaestro
PureBasic Bullfrog
PureBasic Bullfrog
Posts: 8215
Joined: Wed Jul 06, 2005 5:42 am
Location: Fort Nelson, BC, Canada

Post by netmaestro »

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.
BERESHEIT
AND51
Addict
Addict
Posts: 1040
Joined: Sun Oct 15, 2006 8:56 pm
Location: Germany
Contact:

Post by AND51 »

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.
PB 4.30

Code: Select all

onErrorGoto(?Fred)
freak
PureBasic Team
PureBasic Team
Posts: 5844
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Post by freak »

netmaestro 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.
This has been planned for quite a while, but it isn't really a priority. So better don't hold your breath ;)
quidquid Latine dictum sit altum videtur
User avatar
USCode
Addict
Addict
Posts: 907
Joined: Wed Mar 24, 2004 11:04 pm
Location: Seattle, USA

Packer support of zlib

Post by USCode »

+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?!?! :twisted:
Thorium
Addict
Addict
Posts: 1268
Joined: Sat Aug 15, 2009 6:59 pm

Post by Thorium »

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.
User avatar
USCode
Addict
Addict
Posts: 907
Joined: Wed Mar 24, 2004 11:04 pm
Location: Seattle, USA

Post by USCode »

Yeah I was hoping this would make it into 4.40 as well but after looking at the 4.40 changelog I can't complain! They've been busy!
Fingers crossed for the next release. 8)
Post Reply