ARSD PNG memory usage

[Joerg Joergonson via Digitalmars-d-learn]

On Saturday, 18 June 2016 at 00:56:57 UTC, Joerg Joergonson wrote:
> On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:
>>[...]
>
> Yes, same here! Great! It runs around 122MB in x86 and 107MB 
> x64. Much better!
>
>>[...]
>
> Yeah, strange but good catch! It now works in x64! I modified 
> it to to!wstring(title).dup simply to have the same title and 
> classname.
>
>> [...]
>
> I have the opposite on memory but not a big deal.
>
>
>> [...]
>
> I will investigate this soon and report back anything. It 
> probably is something straightforward.
>
>> [...]
>
> I found this on non-power of 2 textures:
>
> https://www.opengl.org/wiki/NPOT_Texture
>
>
> https://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt
>
> It seems like it's probably a quick and easy add on and you 
> already have the padding code, it could easily be optional(set 
> a flag or pass a bool or whatever).
>
> it could definitely same some serious memory for large textures.
>
> e.g., a 3000x3000x4 texture takes about 36MB or 2^25.1 bytes. 
> Since this has to be rounded up to 2^26 = 67MB, we almost have 
> doubled the amount of wasted space.
>
> Hence, allowing for non-power of two would probably reduce the 
> memory footprint of my code to near 50MB(around 40MB being the 
> minimum using uncompressed textures).
>
> I might try to get a working version of that at some point. 
> Going to deal with the cpu thing now though.
>
> Thanks again.

Never mind about this. I wasn't keeping in mind that these 
textures are ultimately going to end up in the video card memory.

I simply removed your nextpowerof2 code(so the width and height 
wasn't being enlarged) and saw no memory change). Obviously 
because they are temporary buffers, I guess?

If this is the case, then maybe there is one odd temporary still 
hanging around in png?