Slightly off-topic: has anyone measured the effect of that change on
framerate? I thought it's dipped on me on the Android devices (I disabled
the rendering as a cheap way to get around the OpenGL issue, but it's still
calculating the clouds), but I don't have an FPS counter hooked up.
On Wed, Apr 18, 2012 at 3:25 PM, Barry Gerdes <[email protected]>wrote:
> Hi All
>
> I don't want to be too critical of new features but all the trouble I have
> had with the windows compiling has stemmed from the changes made to the
> display of clouds with the perlin noise additions. Compiling in linux and
> Mac does not appear to have any problems so it is some way that the windows
> compiler (minGW) handles the code.
>
> This change added some upgraded textures which cause no problems but added
> synthesised clouds to some of the solar sytem objects. This display is
> quite unreal with synthetic clouds moving at speeds in the thousands of
> miles per hour and personnally I think it looks awful. However it is easily
> inhibited by editing the ssystem.ini file to display in the older manner.
>
> There were changes to many of the core source files and I suspect that the
> trouble lies in one of these.
>
> There have now been 28 commits to the main branch since the trouble
> appeared and these should not have been made til the problem was rectified.
>
> Barry
>
>
> Barry Gerdes
> Beaumont Hills Observatory
> S 33' 41' 44" E 150' 56' 32"
>
>
>
>
> ------------------------------
> From: [email protected]
> To: [email protected]
> Date: Thu, 19 Apr 2012 05:34:34 +1000
> Subject: Re: [Stellarium-pubdevel] Windows crash with Qt 4.8.*: thread
> safety
>
>
> Hi Bogdan
>
> I have not applied a patch for over four years and can't remember the
> procedure. I tried what i thought was the method but it did not work and I
> can't find the information on applying a patch
>
> Barry Gerdes
> Beaumont Hills Observatory
> S 33' 41' 44" E 150' 56' 32"
>
>
> Date: Wed, 18 Apr 2012 16:31:29 +0300
> From: [email protected]
> To: [email protected]
> Subject: [Stellarium-pubdevel] Windows crash with Qt 4.8.*: thread safety
>
> Hello to all.
>
> It seems that the current crash on Windows when Stellarium is compiled
> in Release mode with Qt 4.8.* is caused by some kind of thread safety
> issue. Stellarium doesn't crash when it's compiled in Debug mode
> because it activates a mutex mechanism normally hidden in an #ifndef.
> The mutex ensures that only one copy of StelPainter is active at the
> time due to some limitation of OpenGL. The attached patch solves the
> crash by enabling the mutex in release mode, but it would be better if
> we can find the root reason.
>
> The crash is reproducible when Stellarium is built in "release mode
> with debug symbols", which allows debugging (see lines 27 and 299-302
> in the main CMakeLists.txt). Stack trace from a crash run:
> 0 ZN7QObjectD2Ev C:\QtSDK\Desktop\Qt\4.8.1\mingw\bin\QtCore4.dll 0
> 0x6e1de8e0
> 1 StelTexture::~StelTexture StelTexture.cpp 148 0xfa6773
> 2 deref qsharedpointer_impl.h 342 0xfd474c
> 3 deref qsharedpointer_impl.h 336 0xfd474c
> 4 ~ExternalRefCount qsharedpointer_impl.h 401 0xfd474c
> 5 ~QSharedPointer qsharedpointer_impl.h 467 0xfd474c
> 6 StelLoadingBar::~StelLoadingBar StelLoadingBar.cpp 50
> 0xfd474c
> 7 StelApp::init StelApp.cpp 330 0xf83fe8
> 8 StelAppGraphicsWidget::init StelAppGraphicsWidget.cpp 58
> 0xf94e9e
> 9 StelMainGraphicsView::init StelMainGraphicsView.cpp 254
> 0x108c703
> 10 StelMainWindow::init StelMainWindow.cpp 107 0x108ede2
> 11 _fu3___ZN11StelFileMgr13fileLocationsE main.cpp 341
> 0x403790
>
> It crashes with a segmentation fault in the destructor of
> StelLoadingBar/StelTexture. Sometimes the crash occurs only when I'm
> running the build with the debugger, depending on what else I'm
> running, which is another indicator of a thread safety issue.
>
> Note that in all cases, the splash image is not displayed, even though
> things are loading in the background (my disk activity indicator is
> flashing, etc.)
>
> Anyway, I really don't have any more time for this now. I will
> probably have more time next week. I can probably test proposed
> changes to the code in the meantime, and it makes more sense to send
> them as patches instead of committing to the repository.
>
> Regards,
> Bogdan Marinov
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to monitoring Big
> Data applications. Try Boundary one-second resolution app monitoring today.
> Free. http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________ Stellarium-pubdevel
> mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to monitoring Big
> Data applications. Try Boundary one-second resolution app monitoring today.
> Free. http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________ Stellarium-pubdevel
> mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Stellarium-pubdevel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Stellarium-pubdevel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
