<div>Hi Robert,</div>
<div> </div>
<div>no need to start a new thread I found my mistake, I was using a <font size="2"></font></div>
<p>osg::ref_ptr<osgViewer::CompositeViewer></p>
<div>instead of a</div><font size="2">
<p>osgViewer::CompositeViewer*</p>
<div></div></font>Now the wglMakeCurrent is working correctly.
<div> </div>
<div>I don't understand why ref pointer produce this kinf of behaviour, sorry to flood you like this.</div>
<div> </div>
<div>Kind regards,</div>
<div> </div>
<div class="gmail_quote">2008/7/3 Robert Osfield <<a href="mailto:robert.osfield@gmail.com">robert.osfield@gmail.com</a>>:<br>
<blockquote style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid" class="gmail_quote">Hi Amalric,<br><br>Wojtek's workaround for the NVidia driver bug was only required for<br>XP, it wasn't required for Visita previosly.   If you have problems<br>
with wglMakeCurrent failing under Visita then this it's likely to be a<br>totally different issue.<br><br>To find out the cause of the problems you are seeing you are best to<br>start a new thread, and in details explain what in your setup works<br>
and what doesn't then others can help step through to see if they see<br>the same problems, and steadily work towards getting a better picture<br>of what works where and finally to some kind of recommendation of what<br>
to do about it.  It could be a driver bug, it could be an OSG bug, it<br>could be an OS bug, it could be hardware fault, it could be an<br>application error, sooo many different options.  Piggybacking of this<br>thread is not the place to do it as it'll only confuse two different<br>
issues.<br><font color="#888888"><br>Robert.<br></font>
<div>
<div></div>
<div class="Wj3C7c"><br>On Thu, Jul 3, 2008 at 9:15 AM, amalric alexandre <<a href="mailto:alex.pixxim@gmail.com">alex.pixxim@gmail.com</a>> wrote:<br>> Hi osg-users,<br>><br>> I am currently having problems with wglMakeCurrent wich fails every time it<br>
> is called in<br>><br>> bool GraphicsWindowWin32::makeCurrentImplementation()<br>><br>> Is the fix working for every users ? am I the only one with this behaviour ?<br>><br>> I am using OSG 2.5.3, Vista and NVIDIA 7900GS (forceware 175.19).<br>
> Kind regards<br>> 2008/5/28 Robert Osfield <<a href="mailto:robert.osfield@gmail.com">robert.osfield@gmail.com</a>>:<br>>><br>>> Hi Wojtek, thanks for clarification, I've gone ahead and merged the<br>
>> workaround as it looks perfectly benign.<br>>><br>>> On Wed, May 28, 2008 at 3:54 PM, Wojciech Lewandowski<br>>> <<a href="mailto:lewandowski@ai.com.pl">lewandowski@ai.com.pl</a>> wrote:<br>
>> > Hi Robert,<br>>> ><br>>> > I use it and have not observed any issues. I would say its rather safe.<br>>> ><br>>> > I reported this bug to NVidia. And it looks like they are doing<br>
>> > something to<br>>> > fix the problem. In the meantime they sent me two bit cryptic emails<br>>> > informing they verified and fixed it. Last email was also saying that<br>>> > fix is<br>
>> > awaiting for final verification and closure. I don't know when they make<br>>> > fixed drivers available, though, so I would vote for merging my<br>>> > workaround<br>>> > for time being.<br>
>> ><br>>> > I promise I will let you know or even send the submission removing this<br>>> > workaround when NVidia informs me that fixed drivers are available.<br>>> ><br>>> > Cheers,<br>
>> > Wojtek<br>>> ><br>>> ><br>>> ><br>>> >> Hi Wojtek,<br>>> >><br>>> >> I'm just following up on your workaround for the NVidia WindowsXP<br>>> >> multi-thread make current bug.   Others have reported problems since<br>
>> >> you posted your fix, and while I know the bug is now Nvidia have<br>>> >> acknowledged the problem, we don't yet know how long it might be to a<br>>> >> fix... so I'm tempted to merge your workaround.<br>
>> >><br>>> >> Thoughts?<br>>> >> Robert.<br>>> >><br>>> >> On Mon, May 12, 2008 at 1:28 PM, Wojciech Lewandowski<br>>> >> <<a href="mailto:lewandowski@ai.com.pl">lewandowski@ai.com.pl</a>> wrote:<br>
>> >>><br>>> >>> Hi again,<br>>> >>><br>>> >>> I have modified GraphicsWindowWin32::makeCurrentImplementation method.<br>>> >>> Code<br>>> >>> attached. This modification solves both garbage in<br>
>> >>> TriangleStrip/TriangleFans and FBO problems. So a complete succes for<br>>> >>> me<br>>> >>> ;-)<br>>> >>><br>>> >>> I am posting it on osg users forum instead of osg submissions because<br>
>> >>> I<br>>> >>> expecty we want some discussion before submitting it.<br>>> >>><br>>> >>> I don't know how this workaroud should be additionaly wrapped. In this<br>
>> >>> form<br>>> >>> its alredy rather non aggressive - second wglMakeCurrent will be<br>>> >>> called<br>>> >>> fairly seldom.  What additional conditions we would like to see tested<br>
>> >>> before applying this worakoround. Any suggestions ? Should I check<br>>> >>> GL_VENDOR, GL_RENDERER, GL_VERSION strings ? Does OSG offer some<br>>> >>> methods<br>>> >>> to<br>
>> >>> query OS, drivers version ?<br>>> >>><br>>> >>> Maybe othe places in the code are more appriopriate for this call.<br>>> >>><br>>> >>> Cheers,<br>
>> >>> Wojtek<br>>> >>><br>>> >>>> Hi Everyone,<br>>> >>>><br>>> >>>> Lets get back to the main topic of this thread ie garbage in<br>>> >>>> Multicore<br>
>> >>>> CPU<br>>> >>>> /<br>>> >>>> NVidia / DualView / Window XP.<br>>> >>>><br>>> >>>> I attached my OpenGL repro for those who are interested. I would be<br>
>> >>>> grateful<br>>> >>>> if somoene could check if my threading code is OK (and maybe simplify<br>>> >>>> it).<br>>> >>>> If it is, I will try to submit the bug to NVidia.<br>
>> >>>><br>>> >>>> Check out what happens when  repeatMakeCurrent variable gets changed<br>>> >>>> to<br>>> >>>> non<br>>> >>>> zero value. This causes repetition of wglMakeCurrent and fixes the<br>
>> >>>> issue.<br>>> >>>> I<br>>> >>>> will try to check this method in OSG next week.<br>>> >>>><br>>> >>>> I am heading back home for the weekend. I will stay online but I<br>
>> >>>> don't<br>>> >>>> have<br>>> >>>> multicore CPU there so I won't be able to check codes till monday.<br>>> >>>><br>>> >>>> Cheers,<br>
>> >>>> Wojtek Lewandowski<br>>> >>>><br>>> >>>><br>>> >>>>> Hi Robert, Paul and J-S,<br>>> >>>>><br>>> >>>>> I don't think I was clear enough. Its too early to say that<br>
>> >>>>> wglMakeCurrent<br>>> >>>>> will be a good workaround for OSG.<br>>> >>>>> I only said that it "relaxed" the problem in my OpenGL repro.<br>
>> >>>>><br>>> >>>>> It looks like first wglMakeCurrent (when renderer thread is started)<br>>> >>>>> does<br>>> >>>>> not initialize properly some internal OpenGL context data. If I<br>
>> >>>>> repeat<br>>> >>>>> it<br>>> >>>>> in second frame everything becomes correct. So if wglMakeCurrent was<br>>> >>>>> a<br>>> >>>>> solution it would be needed only once more on frame.<br>
>> >>>>><br>>> >>>>> But I learned all this using my open gl repro without Display Lists<br>>> >>>>> and<br>>> >>>>> to<br>>> >>>>> be honest I did not checked what will happen if DisplayLists are<br>
>> >>>>> generated<br>>> >>>>> on a first frame (like OSG does). I suspect they might stay screwed<br>>> >>>>> even<br>>> >>>>> if second wglMAkeCurrent gets called.  I am currently trying to<br>
>> >>>>> check<br>>> >>>>> this<br>>> >>>>> out. I just need some more time to investigate.<br>>> >>>>><br>>> >>>>> I got some questions regarding this issue so I decided to inform<br>
>> >>>>> guys<br>>> >>>>> for<br>>> >>>>> whom this is relevant by posting on osg-users. I am certainly far<br>>> >>>>> from<br>>> >>>>> proposing fixes at this moment.<br>
>> >>>>><br>>> >>>>> Wojtek<br>>> >>>>><br>>> >>>>><br>>> >>>>>> Hi Wojciech,<br>>> >>>>>><br>
>> >>>>>> On Fri, May 9, 2008 at 2:16 PM, Wojciech Lewandowski<br>>> >>>>>> <<a href="mailto:lewandowski@ai.com.pl">lewandowski@ai.com.pl</a>> wrote:<br>>> >>>>>>><br>
>> >>>>>>> Problem could be relaxed when wglMakeCurrent gets called before<br>>> >>>>>>> each<br>>> >>>>>>> frame<br>>> >>>>>>> rendering. I noticed that artifacts appeared when wglMakeCurrent<br>
>> >>>>>>> was<br>>> >>>>>>> called<br>>> >>>>>>> only once while worker rendering thread initialization . When<br>>> >>>>>>> wglMakeCurrent<br>
>> >>>>>>> was called every frame artifacts did not appear.<br>>> >>>>>><br>>> >>>>>> wglMakeCurrent "shouldn't" be required if one has a thread per<br>
>> >>>>>> context, one a thread does a wglMakeCurrent() it shouldn't release<br>>> >>>>>> the<br>>> >>>>>> context till this thread calls release context (done with<br>
>> >>>>>> wglMakeCurrent(_hdc, NULL)).<br>>> >>>>>><br>>> >>>>>> As you are finding that the wglMakeCurrent() per frame is required,<br>>> >>>>>> this either suggests that the OpenGL driver is playing fast and<br>
>> >>>>>> loose<br>>> >>>>>> with the graphics context behind the scenes so the app looses the<br>>> >>>>>> context being current, in which case this is very much a driver<br>
>> >>>>>> bug,<br>>> >>>>>> or that the OSG itself is doing makeCurrent on the context from<br>>> >>>>>> another thread or releasing the context when it shouldn't.<br>
>> >>>>>><br>>> >>>>>> Could you put some debug output into GraphicsWindowWin32.cpp's<br>>> >>>>>> makeCurrentImplementation(..) and relaseContextImplementation(..)<br>
>> >>>>>> to<br>>> >>>>>> see if there are being called when you wouldn't expect, printing<br>>> >>>>>> out<br>>> >>>>>> the<br>
>> >>>>>> pointer to the current thread would be useful as well.<br>>> >>>>>><br>>> >>>>>> Robert.<br>>> >>>>>> _______________________________________________<br>
>> >>>>>> osg-users mailing list<br>>> >>>>>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>>> >>>>>><br>
>> >>>>>><br>>> >>>>>><br>>> >>>>>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
>> >>>>><br>>> >>>>> _______________________________________________<br>>> >>>>> osg-users mailing list<br>>> >>>>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
>> >>>>><br>>> >>>>><br>>> >>>>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
>> >>>><br>>> >>><br>>> >>><br>>> >>><br>>> >>><br>>> >>> --------------------------------------------------------------------------------<br>
>> >>><br>>> >>><br>>> >>>> _______________________________________________<br>>> >>>> osg-users mailing list<br>>> >>>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
>> >>>><br>>> >>>><br>>> >>>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
>> >>>><br>>> >>><br>>> >>> _______________________________________________<br>>> >>> osg-users mailing list<br>>> >>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
>> >>><br>>> >>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
>> >>><br>>> >>><br>>> >> _______________________________________________<br>>> >> osg-users mailing list<br>>> >> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
>> >><br>>> >> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>>> ><br>
>> > _______________________________________________<br>>> > osg-users mailing list<br>>> > <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>>> ><br>
>> > <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>>> ><br>>> _______________________________________________<br>
>> osg-users mailing list<br>>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
><br>><br>><br>> --<br>> Alexandre AMALRIC Ingénieur R&D<br>> ===================================<br>> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille<br>> <a href="http://www.pixxim.fr/" target="_blank">http://www.pixxim.fr</a><br>
> _______________________________________________<br>> osg-users mailing list<br>> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
><br>><br>_______________________________________________<br>osg-users mailing list<br><a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br><a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alexandre AMALRIC Ingénieur R&D<br>===================================<br>PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille<br><a href="http://www.pixxim.fr">http://www.pixxim.fr</a>