On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Is 2.1.9 considered to be a stable enough release to
use in place of 2.0.0, and, does it fix the text
threading problems? Thanks.
I consider 2.1.9 more stable that 2.0.0 for sure.
Is it stable enough to become 2.2? Not quite yet, this
Hi Sherman,
I don't have any ideas right now. I will add an external load option
into the text demo multi-threaded portion and see if I can recreate
the crashes.
Robert.
On 9/5/07, sherman wilcox [EMAIL PROTECTED] wrote:
Success! Well, not that kind of success. You see, I was running the
Hi Sheman,
Thanks for testing and changes. I have added static Mutex directly
into the DefaultFont::instance() method rather that add it the
DefaultFont class. It should provide the same effect but keep things
a little bit neater.
I have also added a mutex into Font::GlphTexture to marshal the
Initial testing is encouraging. Tried it out on my quad core box, no
troubles at all. Tested in debug/release with anywhere from 3 to 20
threads running at once. No crashesever, exited cleanly, etc.
Currently compiling on my dual-processor box. Will do longer tests on
that system and my quad
Is 2.1.9 considered to be a stable enough release to
use in place of 2.0.0, and, does it fix the text
threading problems? Thanks.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Success! Well, not that kind of success. You see, I was running the
osgText multithreaded sample you wrote...it would not crash. Ran
perfectly on all my systems. So..I crank up my app, which just so
happens has an option to update osgText objects on a background
thread. CRASH!!! Time and time
Hi Sherman,
On 9/1/07, sherman wilcox [EMAIL PROTECTED] wrote:
If I run with --mt 1 it runs for a bithowever if I change that to --mt
10 it crashes immediately. Tried this on an old dual-proc and a new
quad-core system. Here's the stack from the quad-core:
On 9/2/07, Robert Osfield [EMAIL PROTECTED] wrote:
I'll test it once again to see if I can knock it over.
Just tried running osgtext --mt 10 for 10 frames, repeat 100 times and
it run an exited cleanly all 100 times. Will try 1000 times next.
Robert.
On 8/31/07, Robert Osfield [EMAIL PROTECTED] wrote:
Now I do need qualify pretty solid, its solid if I just leave the
osgtext --mt to do its stuff, but if I enable stats by pressing 's' I
getting freetype warnings printed out to the console and sometimes get
gargabe text on the stats. Since
Hi Sherman,
On 8/30/07, sherman wilcox [EMAIL PROTECTED] wrote:
Here's a trace off the XP32 box. The crash is somewhat 'reliable' in that it
will crash if left running long enough.
Reliable... but time consuming to test out whether you've fixed it... :-)
I have modified osgtext further, add
Hi All,
Thanks the new multi-thread background creation of text in osgtext
I've been able to home in pretty quickly to the problem areas, both in
the core osg and the osgText libraries.
To solve the observed problems I have added several mutexes to
osgText, and as a result am setting pretty
Hi Sherman,
Thanks for the ThreadChecker output, just scanned through it. I don't
know how to interpret all the various warnings.
W.r.t crash on exit, I can recreate that here, and strongly suspect
its an order of destruction issue caused by the DeleteHandler caching
objects. I am considering
An update...left the osgtext --mt demo running all night on both systems,
both had crashed by the time I got up this morning.
On 8/30/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Sherman,
Thanks for the ThreadChecker output, just scanned through it. I don't
know how to interpret all the
On 8/30/07, sherman wilcox [EMAIL PROTECTED] wrote:
An update...left the osgtext --mt demo running all night on both systems,
both had crashed by the time I got up this morning.
Did you get a stack trace for the crashes?
Robert.
___
osg-users mailing
Here's a trace off the XP32 box. The crash is somewhat 'reliable' in that it
will crash if left running long enough.
3ff0()
osg.dll!osg::OperationThread::run() Line 416 C++
OpenThreads.dll!OpenThreads::ThreadPrivateActions::StartThread(void *
data=0x00c921e0) Line 120 C++
Hi Uwe,
Submissions via osg-user run the risk of being missing, the right
place to submit is via osg-submissions.
In this instance I've reviewed your changes but have held back from
merging as I want to establish exactly what parts are breaking before
see changes applied. I also note that your
To help in the process of isolating and fixing the osgText threading
issues users have seen I have modified the osgtext example to do text
creation in a background thread. You can now run it via:
osgtext --mt
What you will see on screen is a box with text strings randomly
We are trying to port an osg 1.2 app to 2.0, and we
frequently get crashes when one thread (which is
building an osg scene that is not yet being rendered)
tries to access fonts while the rendering thread is
rendering text.
Also, on a possibly related note, what happened to
viewer.sync() in osg
Hi Robert,
On 8/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
We are trying to port an osg 1.2 app to 2.0, and we
frequently get crashes when one thread (which is
building an osg scene that is not yet being rendered)
tries to access fonts while the rendering thread is
rendering text.
Robert,
On Monday 27 August 2007 10:39:41 Robert Osfield wrote:
Another user recently reported problems with loading text in a
background thread, which fits your problem too. This was recently and
with the SVN version of the OSG so it looks like the problem persists.
I suspect the problem
20 matches
Mail list logo
