Posted by Michael Bien on
URL: https://forum.jogamp.org/high-memory-consumption-IntIntHashMap-tp2626543p2639325.html

On 03/05/2011 03:33 AM, Sven Gothel [via jogamp] wrote:

On Friday, March 04, 2011 17:14:15 gouessej [via jogamp] wrote:
>
> I'm investigating, it seems to come from GLStateTracker:
> http://forum.jogamp.org/file/n2634263/highMemoryConsumption_IntIntHashMap.png 
>

Please review this change .. (the more the merrier)
  http://jogamp.org/git/?p=jogl.git;a=commitdiff;h=a167589233db343ac22b761d30d9dcd73016fe54

looks good, I added a few things:
https://github.com/mbien/jogl/commit/0b57c668703de3717badf8e779a91e64773d7f61
commit message:

 - using LinkedList as stack replacement for non index based push/pop
 - increased initial map size since the default values already exceeds the default mapsize
 - size()==0 -> isEmpty() (can be significantly faster if the deque impl would change in future)
 - map copy with initial size
 - minor other changes

-michael

Inspecting the code, I realized that popAttrib() even has overwritten the current
client pixel-store state if it's corresponding pushAttrib() didn't happen with CLIENT_PIXEL_..
Which was IMHO a semantical bug .. and should be visible in applications push/pop a lot
with different bitmasks, where the pop would errorneous overwrite the pixel-store state.

This also removes the unnecessary IntIntHashMap creation on popAttrib() at all,
if this was the case of your test case memory peak.

Would be actually nice to have your test case at hand ..

However, pls review my code change - thank you.

~Sven

---

If you reply to this email, your message will be added to the discussion below:

http://forum.jogamp.org/high-memory-consumption-IntIntHashMap-tp2626543p2636570.html

To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.