ARSD PNG memory usage

Fri Jun 17 17:56:57 PDT 2016

On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:
> On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
>> ok, then it's somewhere in TrueColorImage or the loading of 
>> the png.
>
> So, opengltexture actually does reallocate if the size isn't 
> right for the texture... and your image was one of those sizes.
>
> The texture pixel size needs to be a power of two, so 3000 gets 
> rounded up to 4096, which means an internal allocation.
>
> But it can be a temporary one! So ketmar tackled png.d's 
> loaders' temporaries and I took care of gamehelper.d's...
>
> And the test program went down about to 1/3 of its memory 
> usage. Try grabbing the new ones from github now and see if it 
> works for you too.
>

Yes, same here! Great! It runs around 122MB in x86 and 107MB x64. 
Much better!

>
>> Well, It works on LDC x64! again ;) This seems like an issue 
>> with DMD x64? I was thinking maybe it has to do the layout of 
>> the struct or something, but not sure.
>
> I have a fix for this too, though I don't understand why it 
> works....
>
> I just .dup'd the string literal before passing it to Windows. 
> I think dmd is putting the literal in a bad place for these 
> functions (they do bit tests to see if it is a pointer or an 
> atom, so maybe it is in an address where the wrong bits are set)
>

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.

> In any case, the .dup seems to fix it, so all should work on 32 
> or 64 bit now. In my tests, now that the big temporary arrays 
> are manually freed, the memory usage is actually slightly lower 
> on 32 bit, but it isn't bad on 64 bit either.

I have the opposite on memory but not a big deal.

> The CPU usage is consistently very low on my computer. I still 
> don't know what could be causing it for you, but maybe it is 
> the temporary garbage... let us know if the new patches make a 
> difference there.

I will investigate this soon and report back anything. It 
probably is something straightforward.

>> Anyways, We'll figure it all out at some point ;) I'm really 
>> liking your lib by the way. It's let me build a gui and get a 
>> lot done and just "work". Not sure if it will work on X11 with 
>> just a recompile, but I hope ;)
>
>
> It often will! If you aren't using any of the native event 
> handler functions or any of the impl.* members, most things 
> just work (exception being the windows hotkey functions, but 
> those are marked Windows anyway!). The basic opengl stuff is 
> all done for both platforms. Advanced opengl isn't implemented 
> on Windows yet though (I don't know it; my opengl knowledge 
> stops in like 1998 with opengl 1.1 sooooo yeah, I depend on 
> people's contributions for that and someone did Linux for me, 
> but not Windows yet. I think.)

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.