Hi André,
does view.unload() flush the complete cache of a particular view, or
just the last element for instance?
Is there some kind of stack which is "unloaded" or the complete cache?
I'm thinking of onloading the view before I call setSource() again, or
if it is sufficient to call it maybe timer driven?
Moreover, is there a reason why an onload even exists, but there is on
onunload event?
Best,
Michael.
Am 30.01.2008 um 14:27 schrieb André Bargull:
Hello Michael,
there is indeed an internal image-cache for DHTML, but it doesn't
have any size-restrictions, so it'll consume more and more memory
for every new image which has been loaded.
But you can flush that cache by calling the "unload"-method on your
"imagecontainer.image"-view. (This should work, because every view
has got its own cache.)
And it'd be nice, if you create a JIRA-Task to improve the current
caching-method, for example by replacing it with a LRU-Cache.
- André
Hi all,
today I was trying to fix a problem with my image distribution app
while it consumes lots of memory.
In my case I need to display lots (500+) images per patient study
which are loaded from a webserver.
I'm still in the dhtml boat and I'm currently testing my app
agains build 7833 of OL4.1.x.
After some search in the OL Forum and in the book OL in Action I
tried to use setSource() with its additional cache
parameter without luck. My app does is using a timestamp inside
the image url to ensure that the image is not loaded from the
browsers cache. The images are not loaded from the browsers cache,
but they are stored there :-(
I tried to specify setSource("myUrl", "none") without luck. The
memory usage in WindowsXP taskmanager is still growing. Is the
cache option not working, or am I missing something?
Please find attached my sample code showing this issue. Maybe I
need to file a Jire. Could someone please review it and tell me if
I need to add it or jira or how to fix?
