On Friday, 17 June 2016 at 02:55:43 UTC, thedeemon wrote:
> On Friday, 17 June 2016 at 01:51:41 UTC, Joerg Joergonson wrote:
>> Hi, so, do you have any idea why when I load an image with png.d it takes a ton of memory?
>
> I've bumped into this previously. It allocates a lot of temporary arrays for decoded chunks of data, and I managed to reduce those allocations a bit, here's the version I used:
> http://stuff.thedeemon.com/png.d
> (last changed Oct 2014, so may need some tweaks today)
>


Hey, I also stumbled upon this with imageformats decoding PNG. Image loading makes 10x the garbage it should.
Let's see what this threads unveils...

On Tuesday, 16 August 2016 at 16:29:18 UTC, Guillaume Piolat wrote:
> Hey, I also stumbled upon this with imageformats decoding PNG. Image loading makes 10x the garbage it should.
> Let's see what this threads unveils...

leet me know how it is now

On Tuesday, 16 August 2016 at 16:40:30 UTC, Adam D. Ruppe wrote:
> On Tuesday, 16 August 2016 at 16:29:18 UTC, Guillaume Piolat wrote:
>> Hey, I also stumbled upon this with imageformats decoding PNG. Image loading makes 10x the garbage it should.
>> Let's see what this threads unveils...
>
> leet me know how it is now

Reverted back to a stb_image translation to avoid the problem altogether (though it's a bit slower now). Rewriting offending allocations in std.zlib was harder than expected.

On Tuesday, 16 August 2016 at 16:40:30 UTC, Adam D. Ruppe wrote:
> On Tuesday, 16 August 2016 at 16:29:18 UTC, Guillaume Piolat wrote:
>> Hey, I also stumbled upon this with imageformats decoding PNG. Image loading makes 10x the garbage it should.
>> Let's see what this threads unveils...
>
> leet me know how it is now

So I made a small benchmark for testing PNG loading in D
  * dplug.gui.pngload ( = stb_image): 134ms / 4.4mb memory
  * arsd.png: 118ms / 7mb memory
  * imageformats: 108ms / 13.1mb memory

Compiler: ldc-1.0.0-b2, release-nobounds build type