Hi Amalric,
I simply can't answer questions on Win32 front. Getting errors is
wrong, but as how to address them you'll need to rely on Windows
experts.
Robert.
On Mon, Jun 30, 2008 at 11:33 AM, amalric alexandre
<[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> It's good to hear those news ;-)
>
> I'm currently having another problem on removing view (OSG 2.5.2).
>
> When closing a view in function
>
> void GraphicsContext::close(bool callCloseImplementation)
>
> at line 469
>
> if
>
> (makeCurrent()) is returning false.
>
> False is returned from this workaround added 2008/05/12 in
>
> GraphicsWindowWin32::makeCurrentImplementation()
>
> if
>
> ( ::wglGetCurrentDC() != _hdc ||
>
> ::wglGetCurrentContext() != _hglrc )
>
> {
>
> if (!::wglMakeCurrent(_hdc, _hglrc))
>
> {
>
> reportErrorForScreen(
>
> "GraphicsWindowWin32::makeCurrentImplementation() - Unable to set current
> OpenGL rendering context", _traits->screenNum, ::GetLastError());
>
> return false;
>
> }
>
> }
>
>
>
> I wish to know if it is the normal behaviour ?
>
> Kind regards,
>
> 2008/6/28 Robert Osfield <[EMAIL PROTECTED]>:
>>
>> Hi All,
>>
>> There has been several users having problems when trying to do
>> CompositeViewer::addView(..), removeView() after the viewer has been
>> realized. I've investigated this further using Amalric's modified
>> osgwindows.cpp as a base, one fix relating to lack of texturing in new
>> windows I checked in during the week. Today I've been looking at
>> avoiding the window realize code that Amalric's code had to avoid a
>> second a second issue - that is crashes caused by the new windows not
>> being realized.
>>
>> To simplify the addView() code that users have to use in their own
>> apps, I've added automatic realize of new windows that are added view
>> the CompositeViewer::addView(), with this code is only called if the
>> viewer has already been realized. With this change I'm able to remove
>> the workarounds from the test code (i..e no need for realize calls, or
>> stop/startThreading.) I've testing with single threaded and
>> multi-threaded viewers it looks like everything just now works for
>> standard models. These improvements have now been checked into the
>> SVN version of the OSG.
>>
>> The only problem I've seen left to resolve in this area is that on
>> paged databases, the tiles I'm see aren't coming up with textures. I
>> strongly suspect this is due to the paged database releasing
>> osg::Image objects after it's downloads them - something that is good
>> for keeping a lid on memory usage, but is causing problems in this
>> case. This fix would be to disable the unref after apply on all the
>> paged textures, this isn't a viewer issue, rather a database
>> management issue, and something that would need to be done on load of
>> the database, rather than as something we can fix by tweaks in the
>> viewer.
>>
>> Robert.
>> _______________________________________________
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> --
> Alexandre AMALRIC Ingénieur R&D
> ===================================
> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
> http://www.pixxim.fr
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
