I know there have been requests in the past for cache management (which I don't know even exist anymore). This request is to enable cache management for icon objects or icons.
How should this be done? By a simple little cache variable of course! There are advantages to using cache and disadvantages. Here are the modes for the cache variable:
On - When it is 'on', it allows for future reuse. It has the benefit of increasing performance for any icon that is reused. That was the original intention for caching. However, it has the disadvantage of constantly creating new cache as you display each modification to the icon (not an issue with behind the scenes modification, but an issue for real-time display of changes since cache is created upon displaying to each client).
Off - When it is 'off', it disables the use of any caching for that particular icon object. It has the benefit of creating/altering and displaying icons at real-time. This is due to the fact it does not create any cache for each displayed change at real-time. However, it has the disadvantage of needing to recreate said icon (unless it is already built into the compiled RSC file) if used elsewhere. This makes it poor for reuse purposes, but excellent for anything that involves changing at real-time.
With this suggestion/request, it allows programmers to utilize caching when needed. Basically, you can still utilize caching if you reuse said icons. You can turn it off for any icon that does not require caching. I know this won't be available yet, but wouldn't be nice to manage caching for icons in a future version?
ID:1321365
 Jul 11 2013, 1:02 pm
|
|||||||
| |||||||
|
Jul 14 2013, 7:41 pm
|
|
Ill Im
 |
I second this motion.
|
I don't actually understand this request. Icons exist in either two forms: An /icon object which keeps some data in memory and a memory cache, and an actual icon which is in the server cache (.rsc file). When and if the former is finalized by assigning it to an atom or using fcopy_rsc(), it turns into the latter. You can't really turn off caching for a particular icon that's going to get displayed, because if it's being displayed then by definition it has an entry in the .rsc file.
| |
Lummox JR wrote:
I don't actually understand this request. Icons exist in either two forms: An /icon object which keeps some data in memory and a memory cache, and an actual icon which is in the server cache (.rsc file). When and if the former is finalized by assigning it to an atom or using fcopy_rsc(), it turns into the latter. You can't really turn off caching for a particular icon that's going to get displayed, because if it's being displayed then by definition it has an entry in the .rsc file. The cache I'm referring to is the memory cache in this instance since it is an icon that is dynamically created or modified before being displayed. I see what you are saying about turning off the caching though. | |
Bandock wrote:
The cache I'm referring to is the memory cache in this instance since it is an icon that is dynamically created or modified before being displayed. So are you saying you want to use /icon without any memory caching at all? That would be pretty horrendous, inasmuch as the memory caching is what makes /icon workable in the first place. | |
Lummox JR wrote:
Bandock wrote: Only if I don't need caching since every time I display any changes to the icon, more cache is created at a relatively fast rate sometimes (which has slowed down or caused flickering for clients on hosted servers). However, I do like to have an option to turn on caching (by default) when needed since it is great for reuse. I wonder if there is a way to improve display performance without having to turn off caching (where it doesn't cause flickering upon displaying real-time changes to a dynamically created icon). | |
Bandock wrote:
Lummox JR wrote: See, this is where you're losing me. If the icon is displayed, it needs to be in the cache. There's no way around that whatsoever. The only thing that would help your case would be if cache files got refcounted, which they currently don't. In that case an icon no longer in use could be discarded. However that would be a relatively big change. | |
I'm not sure if the OP understands that icon.PROC calls create a new icon file in the cache.
Perhaps the request is something that isn't really possible (I think the OP thinks he can dynamically modify graphic memory on the client from the server). The client simply isn't that smart. | |
For the sake of injecting clarity, here's where things stand with BYOND:
1) Any icon that is displayed to a user must be in the cache, either in the .rsc or .dyn.rsc file. There is no way around this; it can't be changed. 2) Once put into the cache, an icon is not removed. The .dyn.rsc file is obviously discarded when a new world starts up, but for the duration of the world, runtime-created icons stick around. 3) The /icon datum lets you do manipulation on an icon in memory, not displayed to the user, without adding it to the cache. The /icon is added to the cache once it's needed, for instance when it's assigned to an atom. The #2 point is something that could, conceivably, be changed. If nothing used an icon anymore, there would be no reason to hang onto it. However, we don't subject cache files to reference counting, nor do we have a concept of a "hole" in the cache where a valid ID used to be but isn't anymore. Those would be difficult, but not impossible, to change. Now if there's customization going on, sometimes that can be improved by splitting icons up into components. For instance, NEStalgia only allows a certain selection of colors for each component of an icon; it would be feasible to create a master icon for all hair samples (for instance) so each state+color combo was represented, so you'd only need one icon in the cache to represent all possible hair choices. This won't work so well if your colors are completely freeform. | |
Lummox JR wrote:
For the sake of injecting clarity, here's where things stand with BYOND: Yep, that's what I meant. Something like freeform color changing requires new cache to be created. That was something I did for fading effects on icon-based text objects. By changing color for each frame through this method, it was prone to flickering (until the cache was properly created). One solution I did come up with is by creating a pre-rendered text object (either upon creation of a new world or through the DMI Icon Editor) that utilizes color changing effects. After you dynamically create the icon states (which is very handy for speedy changes), this new icon can be reused for the entire session (since it remains in the cache). However, it comes at a cost you should not manipulate again for the entire session (in order to preserve great performance). I have partially implemented such a feature in my SByIo Library V3 test release which can be found here: https://dl.dropboxusercontent.com/u/24250760/BYOND/ Test%20Versions/SByIo%20Library_src.zip (Demo 1.dm uses that feature where you get to pre-render visual text objects.) That reminds me, could you by any chance look into another request I made months ago for a 'loop' argument/parameter for dynamically created icon states Lummox JR @ http://www.byond.com/forum/?post=1005175? My reason is because while you can specify loop for icons made with the DMI Icon Editor, you can't with dynamically created icons/icon states. | |