1
DotNet / Re: Crash during resize of UserControl with embedded RenderWindow
« on: April 07, 2015, 08:01:50 pm »
Thanks for the tips!
As for their purpose: if the GUI thread calls Destroy/Create at the same time the rendering thread calls Draw (or something) then we might have a race - if m_Window.Dispose had been called but m_Window hadn't yet been set to null, for example, we might try to draw to the disposed object (right...?). These will probably be converted into something more elegant, but during testing they will stay there.
EDIT: Altering the view as suggested in that tutorial works wonderfully - thanks for the link.
At this point, zsbzsb, I practically owe you a co-author credit on my application
As it stands I believe the class to be fully functional - if there are other concerns to be considered in a multithreaded application, though, I might need to make some changes (e.g. I am not entirely sure which of the built-in RenderWindow functions won't lead to a race, so some uses of Monitor might be unnecessary). I might just do away with the Monitor stuff entirely and assume that it will be handled externally (if needed), as this is more in line with what is expected of SFML.
Feel free to toss any other suggestions my way - revised code below.
Quote
Why don't you resize the view like you are supposed to do?I don't know how I missed that section of the View tutorial, but that would probably do the trick. Ideally the RenderControl would work when its DockStyle was set to fill, but that caused a lot of trouble initially... I'll give this a try and report back.
Quote
You never dispose the old windowGood catch. Ran into trouble when testing before I'd finished the class, and must have missed that.
Quote
Not to mention SFML doesn't exactly play nicely with threads in some situations, so I don't understand why you have all these monitor calls all overThis control will eventually be incorporated into an application where rendering runs in a separate thread than the GUI, as is necessary to keep the GUI from hanging when using a rendering loop. After I shifted construction of all OpenGL-related objects to the rendering thread I haven't had any trouble when using SFML in my multithreaded app... if you have/know of any specific concerns, I'd be happy to hear them, though!
As for their purpose: if the GUI thread calls Destroy/Create at the same time the rendering thread calls Draw (or something) then we might have a race - if m_Window.Dispose had been called but m_Window hadn't yet been set to null, for example, we might try to draw to the disposed object (right...?). These will probably be converted into something more elegant, but during testing they will stay there.
Quote
Why don't you just store a context setting struct as a member variableI had been considering making these changeable, but then I noticed that SFML doesn't let you do this and figured I shouldn't either. In retrospect I don't really know why you'd want to change them anyway. That will be fixed as soon as the more important bits are taken care of.
EDIT: Altering the view as suggested in that tutorial works wonderfully - thanks for the link.
At this point, zsbzsb, I practically owe you a co-author credit on my application
As it stands I believe the class to be fully functional - if there are other concerns to be considered in a multithreaded application, though, I might need to make some changes (e.g. I am not entirely sure which of the built-in RenderWindow functions won't lead to a race, so some uses of Monitor might be unnecessary). I might just do away with the Monitor stuff entirely and assume that it will be handled externally (if needed), as this is more in line with what is expected of SFML.
Feel free to toss any other suggestions my way - revised code below.
(click to show/hide)