even if they have had DataVariance DYNAMIC explicitly specified. Then
when an application attempts to dynamically update the geometry in the
frame loop the primitive sets and data arrays are no longer as
expected, leading to display and/or memory corruption.
Attached is a simple fix."
Note from Robert Osfield, tweaked Colin's changes so that it uses != DYNAMIC rather == STATIC in the additional test.
Merged from svn/trunk using:
svn merge -r 10479:10480 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/osgUtil/Optimizer.cpp
Barrier operations. The error is with atomic operations in the
win32 condition implementation. The attached sample program will
reliably trigger with as few as three threads and a dual core system,
though sometimes it will take 65,000 iterations.
2.8.1 was the base for these changes
Win32ConditionPrivateData.h
Win32ConditionPrivateData::wait does two operations to decrement
waiters_ then read, when InterlockedDecrement decrements and returns
the value in one operation. The two operations allows another thread
to also decrement with both getting 0 for an answer.
Win32ConditionPrivateData::broadcast is using waiters_ directly
instead of using the w value read earlier, if it was safe to use
waiters_ directly there would be no need for InterlockedGet or w.
overview of deadlock in barrier with three threads
one thread in broadcast, 2 threads in wait,
release semaphore 2, waits on waiters_done_
both threads wake, decrement waiters_, get 0 for w,
<logic error here>
one calls set waiters_done_,
broadcast thread comes out of waiters_done_,
other thread calls waiters_done_, (which leaves waiters_done_ in the
signaled state)
<sets the trap>
broadcast thread returns releases mutex, other threads get
mutex and also return,
next barrier, first two threads enter wait, one goes to broadcast, release
semaphore 2, skips waiters_done_ as it had been released last time
returns, processes, enters the barrier for the next barrier operation
and waits,
three threads are now in wait, two have the previous barrier phase,
one the current phase, there's one count left in the semaphore which a
thread gets, returns, enters the barrier as a waiter, sleeps, and the
deadlock is completed"
Merged from svn/trunk using:
svn merge -r 10456:10457 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/OpenThreads/win32
I found that changing the alignment of a text object does not work properly if the text contains newline characters. I've attached a simple test case that shows the problem. If I set the text AFTER setting the alignment, everything works fine. But if I set the text BEFORE setting the alignment then the text is displayed incorrectly.
The fix is very simple. Instead of calling computePositions() in TextBase::setAlignment(), it calls computeGlyphRepresentation(). I've attached the modified TextBase.cpp."
Merged from svn/trunk using:
svn merge -r 10375:10376 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/src/osgText/TextBase.cpp
"The dragger's corner tabs are no longer in the corners."
this fix places the cornertabs back in the corners.
(the manipulator does not make sense otherwise)."
GL_EXT_framebuffer_blit extension is available. This is due to the early
return from the constructor if this is missing.
As far as I read the standard extension documents, this blit call is not
required to have packed depth stencil fbos.
The change fixes this and allows packed stencil attachments on machines
without the multisample blit command."
Merged from svn/trunk using:
svn merge -r 10326:10327 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk
master and the slave camera are placed on the same
GraphisContext, or when the master camera and slave camera are
assigned to different Camers. Note normally one doesn't mix
master with GraphicsContexts and slave cameras so neither case is
common."
"Refactored the adaption of X11 key symbols into OSG key events to fix problems with handling wide range of locales."
From Mathias Froehlich, "This frees some memory that is allocated by the X11 functions."
