On Tuesday 31 May 2011 14:17:23 Mathias Fröhlich wrote:
> So, what to do:
>
> The real solution is hard. Tim effecs code *probably* shows how to solve
> this. I have never double checked if this is done in a waterproof way, but
> I would guess this is ...
>
> A solution that might at least work
Good morning,
On Monday, May 30, 2011 19:54:31 ThorstenB wrote:
> On 30.05.2011 19:25, Stefan Seifert wrote:
> > The segfault happens when the main loop thread tries to
> > access GL information. I know next to nothing about openGL programming
> > but I seem to recall that it's not allowed to acc
On 30.05.2011 19:25, Stefan Seifert wrote:
> The segfault happens when the main loop thread tries to
> access GL information. I know next to nothing about openGL programming but I
> seem to recall that it's not allowed to access the same GL context in
> different
> threads. So how is this supposed
On Friday 13 May 2011 11:03:24 Anders Gidenstam wrote:
> Presumably it will also increase the risk of triggering any race condition
> and/or unsynchronized data access bugs that may be lurking in the code.
> There are some known ones (e.g. during the creation of a particle
> system) but there coul
On Fri, 13 May 2011, Stefan Seifert wrote:
> multithreading-mode is disabled by default with a note, that it breaks
> screenshots. Is this the only reason or is it known not to be stable?
Presumably it will also increase the risk of triggering any race condition
and/or unsynchronized data access
Hi!
While trying to get some double digit frame rates out of FG next, I tried to
enable OSG multi threading in preferences.xml, but that leads to a segfault:
#0 0x772af357 in glGetString () from /usr/lib64/libGL.so.1
#1 0x00ab9b3a in SGIsOpenGLExtensionSupported (extName=0xbe07
6 matches
Mail list logo
