Hi Daniele, On 11 January 2018 at 15:00, Daniele Nadalutti <[email protected]> wrote: > my application, based on multiple instances of osgViewer sharing the graphic > context and with the possibility of dynamically creating and deleting those > osgViewers, was experiencing many crashes with OSG 3.5.x, due to a bug > similar to the one described in this Forum, topic number 16745 (sorry, I > cannot post links :( ).
I would not recommend using multiple instances of osgViewer or sharing graphics context unless you are restricting the application to just using SingleThreaded. Creating and destroying viewers is not something I would recommend either. It's far better to close windows and stop call frame loops rather than deleting and recreting. However, I know nothing about your specific application needs so I can't say exactly what the best approach would be. All I can say is from your description your usage case does sound like it's designed to be inefficient and potential unstable, quite a few red flags are raised. > After moving to 3.4.1, the number of crashes decreased a lot, and they are > almost absent after applying the patch attached in this thread. > > Has it already been integrated to the trunk or is there a "more appropriate > way" to handle the problem highlighted by Colin? There are range of improvements to trunk, whether they address the crashes you are seeing or not I can't say, issues get reported we fix them, it's continous cycle with lots of submissions and fixes going by. All I can say is that your description of your application usage case raise red flags regardless of what is happening on the OSG side. I would recommend that you explain to use the particular application behaviour you are after and we can then recommend how we'd tackle this. If it does turn out that your application approach is appropriate and it's just a bug on the OSG side the best way to progress would be to create a small test example that illustrates you usage case, as it's so convoluted as things stand I wouldn't dare trying to infer anything about what may or may not be wrong with your application or on the OSG side. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
