BYOND Version:489
Operating System:Windows 7 Pro 64-bit
Web Browser:Firefox 6.0
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
When you put an icon in a grid using either the \icon macro or the <img> tag with the \ref macro, Dream Seeker allocates memory for the entire icon, even if you only wanted a specific state. Not only that, but if you ask again for the exact same icon and icon_state combo, it allocates all that memory again, and it never frees the memory! That leads to obscene amounts of memory usage. (Which can lead to crashes from lack of memory.)

Numbered Steps to Reproduce Problem:
  1. Make a grid in your interface file.
  2. Set the cells property to a large number of cells. (e.g. 500)
  3. Get an icon that is large, but has small individual icon states. ('Large' can be about 3KB.)
  4. Use output() to send a particular icon state from the icon to the grid in different cells.
  5. Use either \icon or <img> with \ref to show the image.
  6. Just repeat this until many different cells all have the same image.

Here is a demo that shows the bug in action.

Code Snippet (if applicable) to Reproduce Problem:
set desc = "Works fine."
set desc = "Uses obscene amounts of memory."
winset(src, "grid", "cells=1x500")
for (var/i = 1, i <= 500, ++i)
winset(src, "grid", "current-cell=1,[i]")
src << output("<img src=\ref[file] iconstate='state'>", "grid")

Expected Results:
It should only allocate enough memory to show the one chosen icon_state.
It should only allocate memory for the entire icon one time and reuse the icon in memory.

Actual Results:
When putting an image in the grid using the \ref macro, it allocates new memory
for the entire icon without freeing that memory every time.

Does the problem occur:
Every time? Or how often? Always.
In other games? Yes.
In other user accounts? Yes.
On other computers? I do not know.

When does the problem NOT occur?
If you have a small icon, then it only allocates memory for that icon each time, which can save memory allocation, but that's not a fix.
It always occurs as long as the icon is big enough.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
I'm not sure, but I'll assume it's been here for a while.

I don't know of any workarounds that completely eliminate the problem.
I'll try to find one.
A possible workaround is to get the icon downloaded from a website, instead of from within the game itself. (By using the enable-http-images property.) A nice solution would be the ability to get images from the user's cache (sent with browse_rsc) with this method.
Downloading the icon from a website will make no difference in how the memory is allocated. Generally speaking I agree though that better handling of the allocations to reuse the various states would be a good idea.

I'll have to check out how the icon state case is handled because if you're right that it's never freeing that memory, that's obviously bad news.
I still have the issue when I use <img src=\ref['icon2.dmi']> without specifying the icon state.

When I run the project and use the 'FillGrid2' verb, Task Manager tells me it's using about 980MB of memory. Closing the window with the grid doesn't free the memory, either. It only gets freed when I close Dream Seeker. (Hopefully the operating system isn't having to free that memory.)

(The actual file is 2,866B, so 500 of that would use about 1.37GB. It crashes on my computer before that is reached, given I also have Firefox open, since I only have 3GB of RAM.)
It does free the memory if I update the grids with another image. (If I call FillGrid2 and then FillGrid1, the memory is freed.)

However, if it fails to allocate the memory, a bug remains where it doesn't seem to properly parse the html of the grid, and it just displays it as text.
Okay, so the problem isn't that the memory isn't freed, only that the same allocation is not reused across different grid cells?
Yeah, that'd be the issue.
No memory leaks. (Phew.)
In that case this isn't a bug. Moving to feature requests.
Well, there's another bug that, if fixed, would eliminate the need for this, but I have trouble reproducing it in other games.
I guess I'll have to get to that eventually. (I think I may have found the way to reproduce it by using big icon files.)