» Memoryleak in Text (EX9) Plugin
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

Memoryleak in Text (EX9) Plugin

question open node

milo 10/09/11 - 08:46

helo,

it seems that the text plugin (v25.1 as well as v26) has a serious memory leak. Every time the Text-Input changes, a new block of memory is allocated but never will released again. (utf8 as well as ansi)

a guess is that it has something to do with the drawString method and a missing Dispose somewhere.

cheers,

i.

5 replies 0 new

link | Flag this reply as a solution. david (diplomate) 11/09/2011 - 12:45

this seems a serious bug to me. since most e.g multilanguage exhibits probably using text (ex9).

devvvs. any chances this could be fixed soon? tonfilm, joreg?

link | Flag this reply as a solution. bo27 (translator) 11/09/2011 - 13:04

confirm this bug!
if you create new Text(EX9) node in beta26 you'll face this memory leak.
Text nodes in a patch created in beta25.1, are opens in beta26 as Text (EX9.Legacy) and have no memory leak at all! so it solution for licensied users for now.

link | Flag this reply as a solution. david (diplomate) 13/09/2011 - 11:12

hmm. bo's "solution" does not work for me. still got an increasing memory usage. deleting or reseting the node de-allocates the memory though.
gregns. any idea?

link | Flag this reply as a solution. david (diplomate) 13/09/2011 - 11:20

while disabling (enabled pin) the node in beta25.1 doesn't change anything, in beta26 it de-allocates the memory.

though in beta26 from the beginning the requirement for memory is 3 times as high as in beta25.

link | Flag this reply as a solution. Elias (devvvv) 10/11/2011 - 02:02

first of all this is NOT a memory leak. by deleting the node, removing the layer connection or disabling it the memory consumption goes back to normal (though we call the last one an undesired behaviour, because it leads to glitches). so all resources are cleaned up properly.

the plugin uses ID3DXFont::DrawText to draw the text. this method caches each character it has to draw in form of a texture. the size of the texture depends on the size of the text.

this test patch creates about 100 new characters each second.

in case of ANSI there are only 256 characters, the internal texture cache of DrawText will therefor be filled after about 3 seconds. in case of UTF8 there are up to 2^32 characters, so it will take about 1.3 years (!) till the cache won't miss anymore ;)

you can easily test this by adding a modulo of 256 to the test patch. switch between ANSI or UTF8 and the memory consumption will stay the same.

sadly we can't do anything about the caching behaviour of the DrawText method, but what we can do is adding a few hidden pins in order to release all resources and therefor lower memory consumption and pins to control the pre-loading behaviour of various characters. hope this helps.

anonymous user login

Shoutbox

~3h ago

Urbankind: circuitb:Wrongcop is epic! :)

~4h ago

joreg: @tobi: use GetSlice() as the patch i referred you to is demonstrating. or start a forum thread with your patch.

~4h ago

TobiTobsen123: hmm yes i can see the values...but how to handle them as seperate values? I need to forward them via TCP/IP...

~6h ago

joreg: @tobi: OSCDecoder helppatch has a section: OSC_Advanced (bottomright) that demoes decoding of multiple messages

~6h ago

TobiTobsen123: I'm using an OSCDecoder, it receives two arguments...works but how can I seperate the arguments into two seperate values

~9h ago

u7angel: @mediadog, make it a forum question.

~9h ago

u7angel: @mediadog, tty renderer ?

~11h ago

microdee: however non-conductive objects are invisible for this so the pencil and the sticks in the video are still a mysteries