Hi Wojtek,
I'd be inclined to keep that hack in there for a while longer. It
isn't doing any harm.
Robert.
On Wed, Aug 27, 2008 at 8:58 AM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Yesterday on Nvidia website appeared new driver version 177.92. I made a
> check and it look
Hi All,
Yesterday on Nvidia website appeared new driver version 177.92. I made a
check and it looks like this driver fixes the issues for which I made my
duplicated MakeCurrentContext workaround. So it looks like we may now remove
this workaround.
Unfortunately this driver has Beta status and
On Thu, Jul 3, 2008 at 10:13 AM, amalric alexandre
<[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> no need to start a new thread I found my mistake, I was using a
>
> osg::ref_ptr
>
> instead of a
>
> osgViewer::CompositeViewer*
>
> Now the wglMakeCurrent is working correctly.
>
> I don't understand wh
Hi Robert,
no need to start a new thread I found my mistake, I was using a
osg::ref_ptr
instead of a
osgViewer::CompositeViewer*
Now the wglMakeCurrent is working correctly.
I don't understand why ref pointer produce this kinf of behaviour, sorry to
flood you like this.
Kind regards,
2008/7/3
Hi Amalric,
Wojtek's workaround for the NVidia driver bug was only required for
XP, it wasn't required for Visita previosly. If you have problems
with wglMakeCurrent failing under Visita then this it's likely to be a
totally different issue.
To find out the cause of the problems you are seeing
Hi osg-users,
I am currently having problems with wglMakeCurrent wich fails every time it
is called in
bool GraphicsWindowWin32::makeCurrentImplementation()
Is the fix working for every users ? am I the only one with this behaviour ?
I am using OSG 2.5.3, Vista and NVIDIA 7900GS (forceware 175.1
Hi Wojtek, thanks for clarification, I've gone ahead and merged the
workaround as it looks perfectly benign.
On Wed, May 28, 2008 at 3:54 PM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> I use it and have not observed any issues. I would say its rather safe.
>
> I reported this
Hi Robert,
I use it and have not observed any issues. I would say its rather safe.
I reported this bug to NVidia. And it looks like they are doing something to
fix the problem. In the meantime they sent me two bit cryptic emails
informing they verified and fixed it. Last email was also saying
Thanks J-S,
So I'd suggest merge your change as is. I was hoping for a bit more
feedback from other Windows
users before merging though...
You just needed to ask... ;) I tried the change to GraphicsWindowWin32
with the modified osgprerender example, here at work (Vista 32bit, VS2005,
GeForc
Hi Wojtek, Robert,
So I'd suggest merge your change as is. I was hoping for a bit more
feedback from other Windows
users before merging though...
You just needed to ask... ;) I tried the change to GraphicsWindowWin32
with the modified osgprerender example, here at work (Vista 32bit,
VS2005,
Robert,
GraphicsWindowWin32 only exists under Windows, and given that make
current is so rarely called
and calling it twice with the same value won't break anything I'd
suggest we just integrate your
hack without any extra checks. As I mentioned before the extra checks
could well introduce
bugs
Hi Wojciech,
On Mon, May 12, 2008 at 4:33 PM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> I may test if GL_VENDOR string contains "NVidia" word (case insensitive).
> and GL_RENDERER contains "GeForce" and sometthing that fits "6??0",
> "7??0", "8??0" paterns.
>
> I don't know if there are
I simply mean a test against the driver version, one could come up
with a who sets of tests that
try to isolate when this double make current is applied. Automatic in
as much as its a test that is
done within GraphicsWindowWin32 methods rather than something manually
invoked by the user.
I may
Hi Wojtek,
On Mon, May 12, 2008 at 3:06 PM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> I am not sure what you mean by automatic tests ? Do you want me to write
> some code to check if there are related issues before appling this
> workaround ?
I simply mean a test against the driver versi
Hi Robert,
I've just reviewed your change and it looks benign, and I don't
foresee any problematic side effects on drivers that don't required
this double wglMakeCurrent() calling. The cost of wall
wglMakeCurrent() twice I don't see as something that is likely to
cause particular performance pr
15 matches
Mail list logo