Show Posts
1
Graphics / Re: Each target with its own context
« on: January 18, 2016, 02:12:20 am »you can't share VBO's either, which is a problem because it means in my experiment I have one VBO of the same data for each RenderTexture it is going to be rendered to.I don't get why you think VBOs aren't shareable... Like I said, I've done it many times and it is documented all over the internet, such as here. If binding a VBO in a different context is failing for you, then I can only assume there is something wrong with your code.
From that page: Any object sharing must be made explicitly, either as the context is created or before a newly created context creates any objects.
edit: Believe the explicit sharing between contexts are done with the wglShareLists in Windows and the other OSes has their own functions for it.
And with the current implementation of SFML if I attempt rendering a VBO created in the Windows context on a RenderTexture it fails on the binding because it has not been explicitly shared. My post renderer is an example of where I encountered the problem. If I do not create a VBO for the currently active context, it simply will refuse to bind the VBO. Also notice how I have to fumble around with activate A LOT to make this work in a frankly quite simple 2D application.
(click to show/hide)
So... how are thread-local contexts supposed to support drawing to a RenderTexture in a different thread than the one it was created in? SFML in its current form already requires the user to manually deactivate the RenderTexture's context before moving it to another thread. Your implementation just prohibits moving it at all. I don't see how this is supposed to be better...
This just makes the problem I tried to fix in my PR much worse...
I sincerely suggest you think this through a bit more...
It really doesn't, I remember back in the day I helped a ton of people because of the current "hidden behind" system of contexts messed stuff up for them. My suggestion would ensure an ad-hoc context(which currently is what we have but really bad) to make sure it always works but still allow the user to himself define the context he wants to work with himself because if he is doing that he is probably going to know better than the library does what he wants to do with his context. So So with my example it would guarantee and create a more flexible interface and management of contexts.
Example of creating a render texture and rendering to it in a different thread. The main point of the change is that it will make the user aware of contexts and their relationship with threads which right now is hidden. But like you say yourself, they themselves must still be aware that they need to disable a context in old thread before they are allowed to use it in the new one.
int threadfunc()
{
threadData->aRandomContext.setActive();
// do graphical stuff
}
int main()
{
// Setup application and stuff
aRandomContext.setActive(true);
// Do graphical setup stuff
aRandomContext.setActive(false);
// start thread
}
If the user messes up and forgets to disable the context, he would still end up in the exact same state as with how it works today. The difference here is that he is explicitly made aware of contexts relationship with the thread and if he wants to do a multi-pass post process of the scene then he can do that without constantly switching contexts as well. Or the user just don't care and rely on the underlying system like always.
edit: I am kinda detecting a snarky tone with the whole "create a context for every thread even if no rendering is done" is kinda unnecessary hyperbole. Is my proposition threatening you somehow? For one I gave a quick example to motivate the behavior I found desirable by the library and not the actual implementation of that behavior. Obviously you would lazy allocate the context and your remark can only be seen as an active attempt of degrading my argument. If it is going to be like that we might as well end the conversation. I'll implement my own branch then and keep it to myself.
