Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: sfml equivalent of GetMessage()  (Read 23133 times)

0 Members and 1 Guest are viewing this topic.

Wizzard

  • Full Member
  • ***
  • Posts: 213
    • View Profile
sfml equivalent of GetMessage()
« Reply #45 on: November 06, 2008, 09:39:37 pm »
I think Laurent's main issue is that he doesn't want the context tied to the window. This way, users can load resources before having a window as well as after a window has been destructed. More importantly, they don't have to re-initialize their resources after changing their video mode. So, your first solution is out of the question. I think your second solution is out of the question too, but maybe I misunderstood you. If the context has to be destroyed before the window, it's no good. If you changed it to have the window take a render context, it may be a viable solution. That way, contexts can linger regardless of a window's scope and new windows can use old rendering contexts. Perhaps a reference count could be used, that way no change to the public interface has to be done. A context will only be deleted when everything using it is destroyed.

kfriddile

  • Newbie
  • *
  • Posts: 12
    • View Profile
sfml equivalent of GetMessage()
« Reply #46 on: November 06, 2008, 11:30:11 pm »
Quote from: "Wizzard"
I think Laurent's main issue is that he doesn't want the context tied to the window. This way, users can load resources before having a window as well as after a window has been destructed. More importantly, they don't have to re-initialize their resources after changing their video mode. So, your first solution is out of the question. I think your second solution is out of the question too, but maybe I misunderstood you. If the context has to be destroyed before the window, it's no good. If you changed it to have the window take a render context, it may be a viable solution. That way, contexts can linger regardless of a window's scope and new windows can use old rendering contexts. Perhaps a reference count could be used, that way no change to the public interface has to be done. A context will only be deleted when everything using it is destroyed.


I'm not even sure how to respond to this.  Render contexts are inherently tied to windows.  There is no practical use-case where you would have to load graphical resources before having or after destroying a window (where would you display these resources?).  What's wrong or confusing about having to reload things that were essentially in a container you destroyed?  How does it make sense to have a Window construct off a RenderContext?  This implies that all windows have render contexts, which is completely, conceptually wrong.  I realize that these suggestions would require changing sfml's public interface, but that's ok because I'm also asserting that the existing interface is wrong.  Besides not imposing logical dependencies, the existing interface has also already caused run-time bugs as detailed already in this thread.  I'm not actually asking for these changes as a feature request (since they don't add or remove any useful functionality), just discussing how I would go about solving these problems.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #47 on: November 07, 2008, 08:26:04 am »
Quote
What's wrong or confusing about having to reload things that were essentially in a container you destroyed?

Graphical resources are not owned by contexts or windows. You can create a sprite and display it in any existing window. Otherwise it would mean loading every resource once for every window, which is quite stupid actually ;)

Same remark for re-creating a window: it can happen when you just want to change the video mode; requiring to reload every existing resource in this case wouldn't make sense. I mean, for someone who's not aware of the technical details behind, why would it make sense?

The strong coupling between windows / contexts and resources is a limitation of every 3D API, and then of almost any derived graphics library. And the point is that it doesn't make any sense for almost every user which is not aware of all the technical details involved by the underlying 3D API. I don't want to just make another graphics library which is just a big wrapper around a 3D API and which inherits its limitations, actually I shouldn't even take in account the 3D API when designing my library, it's just an implementation detail.
Laurent Gomila - SFML developer

Imbue

  • Full Member
  • ***
  • Posts: 104
    • View Profile
sfml equivalent of GetMessage()
« Reply #48 on: November 07, 2008, 09:12:29 am »
Quote from: "Laurent"
actually I shouldn't even take in account the 3D API when designing my library, it's just an implementation detail.
Right on, Laurent! :D Seriously, don't ever sacrifice your ideals.

As for the "memory leak", fix it or don't. It doesn't really matter to any reasonable person, as long as you're aware of it and it doesn't grow. Wikipedia calls a memory leak "where the program fails to release memory when no longer needed." Since you're using this memory the entire time it's allocated, is it really even a "memory leak" at all? If you stopped using the memory at some point and didn't free it, then I'd agree that it's totally unacceptable, but that's not the case.

On the GetMessage()/WaitMessage()/Whatever() topic: If this was added I would use it when my game is paused/minimized. If you added it, I bet a lot of others would use it for the same reason. Other than that, I don't personally have any immediate use for it.

In any case, SFML is already an awesome library. Just avoid taking steps backwards (like forcing the user to reload resources when changing video mode) and it'll be an awesome library for some time to come.

Just my 2 cents.

Thanks!

Imbue

  • Full Member
  • ***
  • Posts: 104
    • View Profile
sfml equivalent of GetMessage()
« Reply #49 on: November 07, 2008, 09:25:08 am »
Quote from: "kfriddile"
Quote from: "Laurent"

And you haven't experienced every single situation to say that 100% of leaks can be removed.


Experience doesn't enter into it, just logic.  Anything you create, you can destroy.
If your program is completely sandboxed, then yes. In that case logic says that you can free anything you allocate, no matter how convoluted your design becomes.

However, SFML isn't working in a sandboxed atmosphere. It's calling third party libraries. A third party library could be designed so that you could not free everything you allocate. I'm not saying that's the case here (in fact I very much doubt it is), but that is a possibility (I believe logic should lead you to agree).

Thanks! :D

kfriddile

  • Newbie
  • *
  • Posts: 12
    • View Profile
sfml equivalent of GetMessage()
« Reply #50 on: November 07, 2008, 04:06:48 pm »
Quote from: "Laurent"

Graphical resources are not owned by contexts or windows. You can create a sprite and display it in any existing window. Otherwise it would mean loading every resource once for every window, which is quite stupid actually ;)

Same remark for re-creating a window: it can happen when you just want to change the video mode; requiring to reload every existing resource in this case wouldn't make sense. I mean, for someone who's not aware of the technical details behind, why would it make sense?

The strong coupling between windows / contexts and resources is a limitation of every 3D API, and then of almost any derived graphics library. And the point is that it doesn't make any sense for almost every user which is not aware of all the technical details involved by the underlying 3D API. I don't want to just make another graphics library which is just a big wrapper around a 3D API and which inherits its limitations, actually I shouldn't even take in account the 3D API when designing my library, it's just an implementation detail.


Ok, when we're saying "graphical resource" are we talking about something like simple image data, or something like a texture?  Obviously the first has no logical relation to a rendering context, but the second sure as hell does.  Yes, creating render contexts from a window would mean loading duplicate resources if two windows wanted to display the same texture, and I don't see a problem with that at all.  Why should two windows have the nasty hidden implicit coupling of sharing a context?  It's the same reason globals are bad.

As far as the context recreation not being obvious to someone when changing video modes, you're right.  Under your current design, they wouldn't expect that to happen.  If it was designed the way I've suggested, they WOULD expect it because the interface makes it obvious.  They still don't have to be aware of what's going on under the hood at all.

You should absolutely prevent technical limitations of an underlying API from being passed on to the user (or decide not to use that API in the analysis stage...which is why I'm not using sfml yet :) ).  BUT, there is a reason that every API has that dependency between windows and contexts.  It's not any kind of technical limitation, it's just a logical dependency that's enforced by the API's public interface.

Quote from: "Imbue"
Right on, Laurent! :D Seriously, don't ever sacrifice your ideals.

As for the "memory leak", fix it or don't. It doesn't really matter to any reasonable person, as long as you're aware of it and it doesn't grow. Wikipedia calls a memory leak "where the program fails to release memory when no longer needed." Since you're using this memory the entire time it's allocated, is it really even a "memory leak" at all? If you stopped using the memory at some point and didn't free it, then I'd agree that it's totally unacceptable, but that's not the case.

On the GetMessage()/WaitMessage()/Whatever() topic: If this was added I would use it when my game is paused/minimized. If you added it, I bet a lot of others would use it for the same reason. Other than that, I don't personally have any immediate use for it.

In any case, SFML is already an awesome library. Just avoid taking steps backwards (like forcing the user to reload resources when changing video mode) and it'll be an awesome library for some time to come.

Just my 2 cents.

Thanks!


Correct, don't sacrafice your ideals if you can still convince yourself they're valid in the face of scrutiny.  Failing to do the latter is called being stubborn :P

I would say that memory leaks only make sense to unreasonable people.  Wikipedia's definition is pretty much ok, but your assessment of sfml's handling of the leak is wrong.  He does stop using the memory at some point without freeing it (the end of the program).

Quote from: "Imbue"


If your program is completely sandboxed, then yes. In that case logic says that you can free anything you allocate, no matter how convoluted your design becomes.

However, SFML isn't working in a sandboxed atmosphere. It's calling third party libraries. A third party library could be designed so that you could not free everything you allocate. I'm not saying that's the case here (in fact I very much doubt it is), but that is a possibility (I believe logic should lead you to agree).

Thanks! :D


Haha, you've just described why I decided not to use sfml.  It is a third party library that would force my program to have memory leaks.  The choice is still yours whether or not to use such a library, so control over your program's memory usage is still ultimately yours.

Imbue

  • Full Member
  • ***
  • Posts: 104
    • View Profile
sfml equivalent of GetMessage()
« Reply #51 on: November 07, 2008, 07:40:15 pm »
kfriddile, how would the current "memory leak" effect an SFML user at all? The memory is freed as soon as the application quits. The memory is used until then. The memory usage doesn't grow over time. Why does it make any difference to you what-so-ever?

I think it only has one disadvantage. That is that it shows up as a false positive on tools looking for real memory errors (the kind that accumulate early and often).

Is there any other disadvantage at all?

Quote from: "kfriddile"
Why should two windows have the nasty hidden implicit coupling of sharing a context? It's the same reason globals are bad.
Do you think that MDI is always bad then?

zarka

  • Jr. Member
  • **
  • Posts: 81
    • View Profile
sfml equivalent of GetMessage()
« Reply #52 on: November 07, 2008, 09:32:36 pm »
Quote from: "kfriddile"

Haha, you've just described why I decided not to use sfml.  It is a third party library that would force my program to have memory leaks.  The choice is still yours whether or not to use such a library, so control over your program's memory usage is still ultimately yours.


Or since SFML uses the zlib license, take the parts of SFML you like. Or even better fix the memory leak and use that ;).. and if you fix the leak earn brownie points by submitting a patch :) .. it's open source for a reason!
//Zzzarka

Imbue

  • Full Member
  • ***
  • Posts: 104
    • View Profile
sfml equivalent of GetMessage()
« Reply #53 on: November 07, 2008, 11:27:34 pm »
I added a question on stack overflow about the memory leak problem, for what it's worth. Looks like half the answerers didn't read the question, and there is a huge variety of opinion.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #54 on: November 08, 2008, 09:15:36 am »
Quote
Yes, creating render contexts from a window would mean loading duplicate resources if two windows wanted to display the same texture, and I don't see a problem with that at all. Why should two windows have the nasty hidden implicit coupling of sharing a context? It's the same reason globals are bad.

As far as the context recreation not being obvious to someone when changing video modes, you're right. Under your current design, they wouldn't expect that to happen. If it was designed the way I've suggested, they WOULD expect it because the interface makes it obvious. They still don't have to be aware of what's going on under the hood at all.

Hum... and what about the practical / user point of view? Having a consistent design is one thing, but thinking about features that would be useful in real life also make sense. I feel like your only concern is design, and you actually don't care whether the library is easy to use or not. Why should I put so many limitations if I can just remove them ? One of the properties of OpenGL contexts is that they can be shared, I didn't invented this feature you know ;)
Laurent Gomila - SFML developer

Moomin

  • Newbie
  • *
  • Posts: 6
    • View Profile
sfml equivalent of GetMessage()
« Reply #55 on: January 06, 2009, 12:54:14 pm »
For the memory leak why not use atexit http://www.cplusplus.com/reference/clibrary/cstdlib/atexit.html

Will destroy the context in the right place.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #56 on: January 06, 2009, 01:08:33 pm »
atexit is not better than using the destructor of a global object, i.e. we can't make sure it will happen at the right time.
Laurent Gomila - SFML developer

Moomin

  • Newbie
  • *
  • Posts: 6
    • View Profile
sfml equivalent of GetMessage()
« Reply #57 on: January 06, 2009, 01:48:08 pm »
Ok well a less elegant solution, by controlling the order of construction of global static objects, would be to use compiler directives:


Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #58 on: January 06, 2009, 02:28:06 pm »
Still not a solution. init_priority is too limited, it only controls the order of destruction of a finite set of objects inside a single translation unit.
Laurent Gomila - SFML developer

Moomin

  • Newbie
  • *
  • Posts: 6
    • View Profile
sfml equivalent of GetMessage()
« Reply #59 on: January 06, 2009, 02:43:43 pm »
Um, sorry I think you read it wrong. The link states that in standard c++ objects defined at namespace scope are initialized in order of their definitions in a single translation unit. But using the init_priority attribute overcomes this.

 

anything