Explanation of interactions between Image, Texture, and Sprite?

[cire]

It's fairly trivial to roll up your own sprite/texture type that behave the way you think is more natural from the existing system.  On the other hand, it's nearly impossible to do the reverse from a system where the behavior you prefer is enforced. 

The existing approach is quite flexible, which is something I value in a library.  It doesn't hurt that it doesn't impose overhead for something that I really don't need (and that certainly follows in the grand tradition of C++.)

[FRex]

If you spent half the time you spent disliking the design you could already have a sprite that uses reference counting:
1. Copy and paste sprite.hpp and sprite.cpp
2. Change the name, include guards and add notice under copyright saying that it's not original sfml file but your modified one.
3. Change all sf::Texture * occurences to your* shared pointer of choice(like a dozen or two of brain-dead simple changes).

*As you can see there is slight problem with shared pointers: they are not guaranteed to be in pre 0x standard abiding compiler, boost is too big dependancy, not everyone needs them.

[Laurent]

If you spent half the time you spent disliking the design you could already have a sprite that uses reference counting

Design discussions are important, it helps to improve the library (even when I disagree). Implementing your own stuff is always possible but it doesn't help the community

[ichineko]

I think that things are overcomplicated in your head; or at least biased by your personal background

Can we please stop with the implications that I'm not a C++ developer?  I've been using C++ for something like 18+ years now.  It doesn't really add to the conversation, all it does is make it easy to dismiss anything I say, and that isn't fair to me.

Of couse I could use shared ownership between user and sf::Sprite, but that would involve to manipulate sf::Texture instances through pointers and to allocate them on the heap. That would be a pretty bad design for C++; it would be ok for garbage collected languages.

That's disingenuous.  At the end of the day, that texture is sitting on the vid card, and what you have is an OGL handle referencing it.  You could just as easily have passed that handle around via copy constructors and treated the Texture class as a glorified strong reference that indicated to the OGL driver it should be destroyed when there were no more references.

Thinking about it, is that why you keep implying my background is GC'd languages?  I don't believe that usage pattern would be foreign to any C++ developer with even a little bit of experience, or I should say I hope not.  These types of mechanisms are why I'm able to tell people that if they're manually managing memory in modern day C++, they're either working really close to the hardware, or they're not using C++ optimally.

But I find myself managing the textures much like I would a raw pointer.  In C++.

And I want to be clear, I'm not saying you should have done it this way.  Pros and cons to everything, the approaches I'm referring to have downsides as well.  Slightly larger memory consumption depending on how they're implemented, possible issues in multi-threaded environments, possible performance implications due to the larger size of the objects, and so on.

But your approach has definite downsides too.  expensive copy, manually having to track the lifetime of the texture objects or risk running into a 'dangling pointer'-esque issue, possible multi-threaded issues, and so on.

But I think citing RAII is misguided.

Ultimately it's a question of value semantics vs reference semantics.  I would have expected reference semantics to the underlying texture, but I got value semantics, and it caught me off guard.

But whether you agree with me or not, I see no reason why you couldn't add a small blurb about that onto your code documentation to make it more explicit.  From epxloiter's own mouth in the other thread I linked to, this is a common misconception for people new to SFML.

[ichineko]

It's fairly trivial to roll up your own sprite/texture type that behave the way you think is more natural from the existing system.  On the other hand, it's nearly impossible to do the reverse from a system where the behavior you prefer is enforced. 

I think that's a really good point.  I don't necessarily know that I agree with you about it being more difficult going one direction vs the other, but I can see the argument, and I think it's a good one.

*As you can see there is slight problem with shared pointers: they are not guaranteed to be in pre 0x standard abiding compiler, boost is too big dependancy, not everyone needs them.

Sure, but I like to use the verbiage 'smart object' to refer to objects whose sole purpose is RAII.  Not necessary as full featured as a smart pointer, but that impose some sort of resource management tied to scope.

If you spent half the time you spent disliking the design you could already have a sprite that uses reference counting:

Sure, I had considered that.  But ultimately I dislike moving so far away from the intended design without really good reasons to do so.  That doesn't mean I have to agree with it, but the design isn't going to hamper what I do significantly, it's just surprising imo.

[Laurent]

Can we please stop with the implications that I'm not a C++ developer?  I've been using C++ for something like 18+ years now.  It doesn't really add to the conversation, all it does is make it easy to dismiss anything I say, and that isn't fair to me.

Ok, I'm sorry. I didn't want to imply anything, I just had the feeling that your point of view was somehow biased by your background, which can be an important consideration when talking about design decisions. No offense.

I see no reason why you couldn't add a small blurb about that onto your code documentation to make it more explicit

Of course! I never said I wouldn't. In fact it's already explicitly mentioned in Sprite::setTexture:

The texture argument refers to a texture that must exist as long as the sprite uses it. Indeed, the sprite doesn't store its own copy of the texture, but rather keeps a pointer to the one that you passed to this function. If the source texture is destroyed and the sprite tries to use it, the behaviour is undefined

And it is emphasized too in the 2.0 tutorial that is not online yet.

[ichineko]

Of course! I never said I wouldn't. In fact it's already explicitly mentioned in Sprite::setTexture:

That's not enough or we wouldn't be seeing even more posts about this exact issue.

It's a mistake to think doxygen is proper documentation.

[FRex]

1. SFML code is self documenting, you can freely read, use, modify and distribute it(maybe you don't know how, that's not our problem mr. pre-standard), it's on the most permissive license avaible.
2. There are official tutorials up and more are in writting(in case your c++ experience doesn't cover that and you can't read 1 paragraph worth of text on index.php : RC = RELEASE CANDIDATE, ie.: NOT end version with full documentation).
3. (Almost) every class page of documentation contains: explanation of every single function, use example, long description, if this is not good documentation I don't know what is.

[masskiller]

Justified sarcasm aside all it takes is checking the doc for the functions you plan on using, not just classes in general since they only have an overview and don't necessarily cover everything, but I guess that for an issue such as textures and their lifetime it wouldn't hurt to have it mentioned in the general description of sf::Texture, mainly because it's a very common mistake.

Of course threads about it won't stop with just that, some people just don't read regardless of whether the info is there or not (not necessarily implying you didn't read, so that it won't be misunderstood). I myself have made threads about issues that could have been solved with simple reading just because I didn't check well enough or read too fast.

[Laurent]

That's not enough or we wouldn't be seeing even more posts about this exact issue.

It's in Sprite::setTexture and in the "sprite/texture" tutorial. Where else should it be? Certainly not in the general documentation of sf::Texture, since this issue is related to the link between sprites and textures. There's no problem if you use a texture alone.

Mentioning that the texture is destroyed when its sf::Texture instance is destroyed... well... if it's not obvious then I don't know what's going on in your brain. Then I should do the same with all classes, saying that their destructor destroys the underlying stuff?

The problem here is not the lack of documentation, it's that you started to write code with certain assumptions. I can't write the doc as "if you think xxx then you're wrong, the behaviour is standard". And by "standard" I mean "the destructor destroys". Anything else (shared ownership) would have to be documented, but not that.

[ichineko]

masskiller, I want to thank you.  Despite your disagreement with my position, you've chosen not to be insulting.  I'm unsure as to why the other posters cannot follow from your example.  It's one thing to disagree, even heatedly.  It's another to constantly insult the other party.

It's in Sprite::setTexture and in the "sprite/texture" tutorial.

http://www.sfml-dev.org/tutorials/2.0/
https://github.com/SFML/SFML/wiki/Tutorials

Give me the name of the link on either of those pages that goes to the 'sprite/texture' tutorial.  I mean that seriously, I specifically looked on that page as soon as I realized the sprites, textures, and images interacted in a manner that was unexpected for me.

Mentioning that the texture is destroyed when its sf::Texture instance is destroyed... well... if it's not obvious then I don't know what's going on in your brain. Then I should do the same with all classes, saying that their destructor destroys the underlying stuff?

yes.  Why is that ridiculous?

Exploiter cited RAII.  RAII is about resource cleanup, not resource destruction, and they are not always the same thing.  I understand what's going on underneath, maybe that's part of the problem too.  To me, the OGL driver owns that texture, and anything you do in userspace will be nothing more than requests using a handle.  Given that, and the fact that your APi allows me to hand a single texture to multiple sprites, and I have to ask why you think I should assume that texture is getting destroyed on the vid card when the sf::Texture object is destroyed.  Why is that a better assumption?

From my perspective, it makes no sense.  BUT, it doesn't have to make sense, I just need to know the behavior.  Proper documentation is one way for you to convey that behavior.

The entire reason I started this thread is because I realized my expectations were off, and rather than flail around, I wanted a concrete description of the interactions between these objects.  Proper documentation could have prevented me from creating this thread in the first place.  Despite what you and some of the other seem to want to imply, I did look through the documentation before posting, and that includes the tutorials.


And look at it this way, you may think I'm an asshole, but I'm giving you solid feedback on what I did when I realized things weren't working correctly, and what would have prevented me from creating this thread.  That you're dismissing it as unduly biased is not helping you fix such a common misunderstanding.

[Laurent]

Give me the name of the link on either of those pages that goes to the 'sprite/texture' tutorial.  I mean that seriously, I specifically looked on that page as soon as I realized the sprites, textures, and images interacted in a manner that was unexpected for me.

As I told you in the first post where I mention the tutorial:

And it is emphasized too in the 2.0 tutorial that is not online yet.

In case you didn't notice, SFML 2.0 has not been released yet and none of the graphics tutorials are online

Despite what you and some of the other seem to want to imply, I did look through the documentation before posting, and that includes the tutorials

I never implied that you didn't read the documentation, I simply answered to you saying that "this behaviour should be mentioned".

I understand what's going on underneath, maybe that's part of the problem too

I think we agree on this point, you make too many assumptions. Clear your mind, forget that this is about OpenGL textures. You have an object, and after it is destroyed it can no longer be used. I don't feel like I need to explain that in the doc and/or tutorials.

The only thing to document is the fact that an implicit link exists between a sprite and its texture, and that this link requires to keep the texture alive as long as the sprite uses it. And it is emphasized in both the tutorial and the documentation of Sprite::setTexture.

So if I summarize this whole thread, the actual problem is that the tutorial is not online yet...

you may think I'm an asshole

I don't, I really appreciate your feedback, documentation and design discussions are really valuable to me. And I didn't mean to insult you (I don't think I did, but sorry if you felt insulted by me).

[eXpl0it3r]

I'm unsure as to why the other posters cannot follow from your example.  It's one thing to disagree, even heatedly.  It's another to constantly insult the other party.

You're the one who started to insult people; you also take every comment extremely personal, but then don't stop at nothing and call other people to have a "personality quirk". The way you're acting is very immature and thus I had a very hard time believing that you've actually been working with C++ for a bit.

Exploiter cited RAII.  RAII is about resource cleanup, not resource destruction, and they are not always the same thing.  I understand what's going on underneath, maybe that's part of the problem too.

No RAII is about the lifetime of resources.

Resource Acquisition Is Initialization (RAII) is a programming idiom used in several object-oriented languages like C++, D and Ada. The technique was invented by Bjarne Stroustrup to deal with resource allocation and deallocation in C++. In this language, the only code that can be guaranteed to be executed after an exception is thrown are the destructors of objects residing on the stack. Resource management therefore needs to be tied to the lifespan of suitable objects in order to gain automatic allocation and reclamation. They are acquired during initialization, when there is no chance of them being used before they are available, and released with the destruction of the same objects, which is guaranteed to take place even in case of errors.

To me, the OGL driver owns that texture, and anything you do in userspace will be nothing more than requests using a handle.  Given that, and the fact that your APi allows me to hand a single texture to multiple sprites, and I have to ask why you think I should assume that texture is getting destroyed on the vid card when the sf::Texture object is destroyed.  Why is that a better assumption?

As you say it yourself, this is only the way you think and it's not what one would usually expect.
Tell me, when and how would the texture then get destroyed? Because if the design was intended as you say, the OGL driver would be reference counting on its own, which it isn't. So we would still have to do this after all by hands and thus the OGL driver is not directly the owner.

What I agree with you in this whole discussion, is that it's very confusing that a sprite can reference a texture although it has been destroyed. draw(sprite, texture) might be a better way, but then again the current design is only a way to simplify the usage, so one can manage it...

[ichineko]

You know Laurent, that "you may think I'm an asshole" quote was taken out of context, perhaps you should edit that so it doesn't appear I'm meaning something I didn't actually mean.

So if I summarize this whole thread, the actual problem is that the tutorial is not online yet...

I think that's mostly accurate, they should be online.

I think we agree on this point, you make too many assumptions.

The difference between you and me is that I'm aware of my assumptions, hence the existence of this thread in which I asked for details about the interactions instead of just 'please fix my code'.


You said the following:

Mentioning that the texture is destroyed when its sf::Texture instance is destroyed... well... if it's not obvious then I don't know what's going on in your brain. Then I should do the same with all classes, saying that their destructor destroys the underlying stuff?

That's an assumption, albeit, one you think is reasonable.  And one I do not.

You think my experience with C++ should make assumption X reasonable, I think my experience with OGL should make assumption Y reasonable.  Different assumptions, not less.


So lets not play this game of growling at each other because we want to pretend the other is somehow making less assumptions.


And your documentation isn't enough.  The evidence for that is clear, but I'm going to shut my mouth about it.  It's apparent you would rather spend your time answering the same question every day than to admit that the documentation should probably be improved.  It's your time to spend.

[ichineko]

You're the one who started to insult people; you also take every comment extremely personal, but then don't stop at nothing and call other people to have a "personality quirk". The way you're acting is very immature and thus I had a very hard time believing that you've actually been working with C++ for a bit.

Are you a native English speaker exploiter?  It's an honest question.  The 'personality quirks' line you're referring to;  I was stating that *I* had the personality quirk, not others.  Specifically, I really dislike passive aggressive behavior.   Open hostility is preferable to passive aggressiveness, atleast one of them is honest.  It's a 'quirk' of mine.


Also, it would be a mistake to let your dislike of my posting style affect your evaluation of my expertise as a C++ developer.

No RAII is about the lifetime of resources.

Everyone understood my point, including you.  I will not get into a semantic debate with you about RAII.

As you say it yourself, this is only the way you think and it's not what one would usually expect.

Tell me, when and how would the texture then get destroyed? Because if the design was intended as you say, the OGL driver would be reference counting on its own, which it isn't. So we would still have to do this after all by hands and thus the OGL driver is not directly the owner.

I think maybe we're getting verbiage mixed up?  sf::texture vs the OGL texture is getting confused by the word 'texture'?

You effectively destroy the OGL texture by asking the OGL to destroy it.  Currently, SFML tracks this *anyway*.  It has to because the sprite doesn't hold a reference to the sf::Texture object, but to the OGL texture handle by proxy.  The danger with this approach is that the OGL driver is free to recycle that handle, so if a texture gets destroyed, and another one gets created with the *same* handle, that means your hero sprite may show up as a brick instead of mario.  SFML already has code in place to make sure that doesn't happen, which means you're 90% of the way there now in the current implementation, you just need something to kick off and actually *destroy* the texture when there are no more references from sf::texture objects.

Someone feel free to correct me if I'm misunderstanding the cache mechanism you have in place, I didn't look too closely at the specific implementation.

Please stop trying to imply that it's outlandish for someone to think that an external resource that can be handed to multiple sprite objects might be reference counted (or some other mechanism thereof).  It is not correct, but it *is* an understandable mistake.



PS

The question about being a native English Speaker is not meant as an insult, but as a way to attribute some of the animosity to miscommunication.