Issue is shared_ptr can't handle real caching on his own.
Imagine you want to keep a list of recently used texture cause even if it's not needed right now, it will be in few seconds (i.e. player switch between two zone very often).
Nevertheless you can artificially do it by keeping a LRU linked list of shared_ptr in the TextureSystem/Manager.
Also non-displayed object still in memory would enforce the texture staying loaded.
in a Material : TexturePtr or TextureID ?
Quote:
Also non-displayed object still in memory would enforce the texture staying loaded.
It doesn't have to be. If you want to be able to handle this kind of situations, you could just have the object request the texture ptr when a method Show() is called, and reset it when Hide() is called. The Render Engine itself will determine which objects are visible or not and call Show/Hide accordingly.
Quote:
Issue is shared_ptr can't handle real caching on his own.
And what, IDs can?
As I said, there are different kinds of "caching" you would want to implement. Using shared_ptr doesn't take anything away from you. You can still implement internally anything you want the same way you would do by using ids, with the crucial difference that you can easily query how many objects are using a particular texture at any time. Using ids, you will still end up implementing a kind of reference counting anyway, so why do the extra work?
Quote:Original post by mikeman
Using shared_ptr doesn't take anything away from you. You can still implement anything you want the same way you would do by using ids, with the crucial difference that you can easily query how many objects are using a particular texture at any time.
1. smart pointers (as I said earlier) can be used in a wrong way (passing by value, returning by value, etc.). This is clutter, and the compilers aren't guaranteed to optimize it away.
2. 'How many objects are using a texture' or reference counting can easily be implemented without using smart pointers at all.
3. Using smart pointers generally will not let you know the lifetime of objects. Or don't allow you to know it in a clear and straightforward way.
4. Essencially renderer don't need smart pointers for resources (it don't do allocations).
Just wanted to say, that using smart pointers here sounds very... right. But it isn't, imho. Making things more complex is a path to debugging and pain... :)
Quote:
1. smart pointers (as I said earlier) can be used in a wrong way (passing by value, returning by value, etc.). This is clutter, and the compilers aren't guaranteed to optimize it away.
Doesn't matter. It won't be a bottleneck in any case. If it is you're doing something notoriously wrong.
Quote:
2. 'How many objects are using a texture' or reference counting can easily be implemented without using smart pointers at all.
Yeah, I know you can. The question is, why should you?
Quote:
3. Using smart pointers generally will not let you know the lifetime of objects. Or don't allow you to know it in a clear and straightforward way.
I don't understand that. What do you mean by "the lifetime of objects"?
Quote:
4. Essencially renderer don't need smart pointers for resources (it don't do allocations).
I didn't understand that either. What one has to do with the other(smart pointers and allocations)? Are smart pointers only used by objects that actually allocate the data?
IMO, implementing an id system coupled with your own reference-counting scheme is more prone to errors than using smart pointers.
Quote:Original post by mikemanQuote:
1. smart pointers (as I said earlier) can be used in a wrong way (passing by value, returning by value, etc.). This is clutter, and the compilers aren't guaranteed to optimize it away.
Doesn't matter. It won't be a bottleneck in any case. If it is you're doing something notoriously wrong.
Its clearly not about bottlenecks, but rather about when a first 20 functions in the profiler take less that 1% of the time. None is the bottleneck, but everything chew from the CPU - the idea is that tons of smart pointer passing around the renderer isn't helping, is it? And - it can be used badly, since it is hardly fool-safe.
Quote:Original post by mikemanQuote:
2. 'How many objects are using a texture' or reference counting can easily be implemented without using smart pointers at all.
Yeah, I know you can. The question is, why should you?
Because you want to avoid coupling you resource id, with the reference counting and avoid all of the problems of such coupling.
Quote:Original post by mikemanQuote:
3. Using smart pointers generally will not let you know the lifetime of objects. Or don't allow you to know it in a clear and straightforward way.
I don't understand that. What do you mean by "the lifetime of objects"?
Lifetime of an object (here object means texture) is the interval, when the object exists. When it is created, and more importantly - when it dies.
Quote:Original post by mikemanQuote:
4. Essencially renderer don't need smart pointers for resources (it don't do allocations).
I didn't understand that either. What one has to do with the other(smart pointers and allocations)? Are smart pointers only used by objects that actually allocate the data?
Smart pointers track reference counter, that shows how many objects needs another object. Renderer don't need such tracking of its objects, since it don't acquire resources, don't allocate/deallocate resources during rendering.
Thus, smart pointers are of no interest to the renderer. But when we couple our resources with the idea of smart pointers, we essentially force renderer to use them (pass, store, ...).
Quote:Original post by mikeman
IMO, implementing an id system coupled with your own reference-counting scheme is more prone to errors than using smart pointers.
It's all about knowing the lifetime of resources and caring about it. Managing that is not hard at all, since it happens in a very small and dedicated portion of the engine.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
