Hello,
We are experiencing a strange problem on computers using NVidia GeForce2
MX400 cards (supplied by ASUS, model # V7100 Pro64) after updating the
driver (to version 5.2.1.6).

In the upper-left corner of the view window of our app., we display a
small picture of three orthogonal arrows showing the orientation of the
x, y and z axes. At the ends of each of these arrows, we ouput raster
characters to label each one using glRasterPos and glBitmap. This app.
also has a control-bar docked along the bottom of the window which can
be resized taller or shorter, thus changing the height of the view
window. When this happens, the raster labels are offset vertically by
the same amount that the height of the window changed but in the
opposite direction. That is, if the top of the control-bar is moved up,
making the view window shorter, the labels are drawn farther down from
where they should be, and vice versa for when the top of the control-bar
is moved down. The arrows are drawn in the right place. This only
happens on the first repaint of the window after the change; the next
time the window is redrawn, the raster labels are back where they should be.

The fact that this only occurs after updating the driver leads me to
believe that this may be a bug in the driver. However, I don't
understand why it only happens on the first draw after a change in
height instead of all the time. This makes me wonder if it is some kind
of synchronization thing (?). Another thing bugging me is that so far, I
haven't been able to reproduce the problem in a simple application --
only in our main app.

Below is part of the code for displaying the arrows and labels. Any
ideas you may have on this would be greatly appreciated.

BTW, the OS is WindowsXP and the OpenGL is supplied by Microsoft, is
version 1.4 and has a file version of 5.1.2600.1106.

Thanks,
John

	// fWinWidth and fWinHeight are the width and height of
	// the window in pixels.
	// fLen is the length of the arrows.
	float fLen = float(min(fWinWidth, fWinHeight))/10.0f;
	glMatrixMode(GL_PROJECTION);
	glPushMatrix();
	glLoadIdentity();
	glOrtho(-fWinWidth/2.0, fWinWidth/2.0, -fWinHeight/2.0,
	        fWinHeight/2.0, -fLen, fLen);
	glMatrixMode(GL_MODELVIEW);
	glPushMatrix();
	glLoadIdentity();
	glTranslatef(-fWinWidth/2.0f+fLen+20.0f,
	             fWinHeight/2.0f-fLen-11.0f, 0.0f);
	glMultMatrixf((GLfloat*)&vw); // View rotation only (no
	                              // translation or scaling)
	// Arrows drawn here using GL_LINES and GL_TRIANGLES

	// Now put up raster labels
	glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
	glRasterPos3f(fLen, 0.0f, 0.0f); // Position for X axis label
	glBitmap(8, 9, -2.0f, -2.0f, 9.0, 0.0, &rasters[0][0]);
	// etc.

John Shell wrote:
> Hello,
> We are experiencing a strange problem on computers using NVidia GeForce2
> MX400 cards (supplied by ASUS, model # V7100 Pro64) after updating the
> driver (to version 5.2.1.6).

Did this happen before you updated the driver? What version were you 
running before?

> In the upper-left corner of the view window of our app., we display a
> small picture of three orthogonal arrows showing the orientation of the
> x, y and z axes. At the ends of each of these arrows, we ouput raster
> characters to label each one using glRasterPos and glBitmap. This app.
> also has a control-bar docked along the bottom of the window which can
> be resized taller or shorter, thus changing the height of the view
> window. When this happens, the raster labels are offset vertically by
> the same amount that the height of the window changed but in the
> opposite direction. That is, if the top of the control-bar is moved up,
> making the view window shorter, the labels are drawn farther down from
> where they should be, and vice versa for when the top of the control-bar
> is moved down. The arrows are drawn in the right place. This only
> happens on the first repaint of the window after the change; the next
> time the window is redrawn, the raster labels are back where they should be.

Clearly you just need to throw away the first repaint. :-)

Actually, you might be getting a repaint before a window resize -- dump 
out the events to see if this might be the case.

If the event handling seems correct, try running with a software 
renderer to see if it happens there.

> BTW, the OS is WindowsXP and the OpenGL is supplied by Microsoft, is
> version 1.4 and has a file version of 5.1.2600.1106.

Well, the OpenGL is really supplied by NVidia, just the top OpenGL32.dll 
is supplied by Microsoft.

--
Andy V

Andy,
Thank you for your response.

On 4/29/2004 8:52 PM, Andy V wrote:
> John Shell wrote:
>> Hello,
>> We are experiencing a strange problem on computers using NVidia GeForce2
>> MX400 cards (supplied by ASUS, model # V7100 Pro64) after updating the
>> driver (to version 5.2.1.6).
> 
> Did this happen before you updated the driver? What version were you 
> running before?
> 

No, it never happened before the update.

> 
> Clearly you just need to throw away the first repaint. :-)
> 
> Actually, you might be getting a repaint before a window resize -- dump 
> out the events to see if this might be the case.
> 
> If the event handling seems correct, try running with a software 
> renderer to see if it happens there.
> 

Good idea. With software rendering, the problem doesn't occur, so (I
think) it's safe to say that it is the driver/card.

Actually, you're first suggestion isn't so bad either. If I do
back-to-back redraws, the problem doesn't show up.

Right now, our work-around for this is to set a registry value on any
customer computer that is experiencing this problem. Our software will
then detect this value and, if set, will put up the labels using GDI
calls (i.e., TextOut calls) instead of OpenGL calls. However, because we
are using double buffering, the TextOuts must be after the SwapBuffer
which means that the labels flicker as the view is rotated, zoomed or
panned. That's no big deal -- I just don't like it from a programming
point-of-view because it makes the code ugly (uglier).

John

John Shell wrote:

> Right now, our work-around for this is to set a registry value on any
> customer computer that is experiencing this problem. Our software will
> then detect this value and, if set, will put up the labels using GDI
> calls (i.e., TextOut calls) instead of OpenGL calls. However, because we
> are using double buffering, the TextOuts must be after the SwapBuffer
> which means that the labels flicker as the view is rotated, zoomed or
> panned. That's no big deal -- I just don't like it from a programming
> point-of-view because it makes the code ugly (uglier).

Just a note of warning -- this will not work the same way on all 
graphics boards. You may be lucky.

--
Andy V

John Shell wrote:

> Good idea. With software rendering, the problem doesn't occur, so (I
> think) it's safe to say that it is the driver/card.

The jury is still out. It is easy to have a bug that works the way you 
want in one configuration and differently in another configuration.

--
Andy V

Andy,
Thanks for your input. Regarding the warning about my work-around
possibly not working on all cards: Hopefully, we won't have the raster
problem on other cards. Our company manufactures and sells numeric
control machine tools and we supply both the hardware and software.
Therefore, we can test any graphics cards before we distribute them.
However, since the computer hardware is standard PC hardware, the
customer could swap graphics cards. I'm not sure what our company's
policy in this case would be -- it might become the customer's problem
at that point.

BTW, I'm curious how the TextOuts might act on other graphic cards.

Anyway, if the software rendering test doesn't necessarily implicate the
driver/card, any other suggestions for things to try, or for a better
work-around?

Thanks again,
John

On 5/3/2004 6:24 PM, Andy V wrote:
> 
> The jury is still out. It is easy to have a bug that works the way you 
> want in one configuration and differently in another configuration.
> 
> --
> Andy V
> 

John Shell wrote:
> Andy,
> Thanks for your input. Regarding the warning about my work-around
> possibly not working on all cards: Hopefully, we won't have the raster
> problem on other cards. Our company manufactures and sells numeric
> control machine tools and we supply both the hardware and software.
> Therefore, we can test any graphics cards before we distribute them.
> However, since the computer hardware is standard PC hardware, the
> customer could swap graphics cards. I'm not sure what our company's
> policy in this case would be -- it might become the customer's problem
> at that point.
> 
> BTW, I'm curious how the TextOuts might act on other graphic cards.

Here is a "deep pixel" configuration: RGBA0 in bits 0 to 31, RGBA1 in 
bits 31 to 63 and a bank select bit 64. OpenGL renders to the back 
buffer, and SwapBuffers simply complements bit 64 for all the pixels in 
the window.

However, the Win32 graphics system doesn't know about two buffers -- it 
always renders to bits 0 to 31. Thus, sometimes you will get the right 
results and sometimes Win32 will render to the back buffer.

> Anyway, if the software rendering test doesn't necessarily implicate the
> driver/card, any other suggestions for things to try, or for a better
> work-around?

I don't have any magic bullets; I generally just try to reduce the 
problem to a small reproducer and try it on a number of different 
boards. Then I can send that to the maintainers.

I just swapped graphics boards myself, and have started having problems. 
Is it my program or the driver? I suspect the driver but other 
applications are doing just fine on that board. Clearly I am doing 
something sufficiently out of the ordinary that I'm confusing the 
implementation. Or do I just have a bug, and I've just been lucky?


--
Andy V

Andy V wrote:
> 
> I just swapped graphics boards myself, and have started having problems. 
> Is it my program or the driver? I suspect the driver but other 
> applications are doing just fine on that board. Clearly I am doing 
> something sufficiently out of the ordinary that I'm confusing the 
> implementation. Or do I just have a bug, and I've just been lucky?
> 

Did you go from NVIDIA to ATI..?

ATI cards are a lot more fussy about what they accept,
but getting your program working on an ATI card will
usually make the program more "correct".



-- 
<\___/>          "To err is human, to moo bovine."
/ O O \
\_____/  FTB.    For email, remove my socks.

fungus wrote:

> Andy V wrote:
> 
>>
>> I just swapped graphics boards myself, and have started having 
>> problems. Is it my program or the driver? I suspect the driver but 
>> other applications are doing just fine on that board. Clearly I am 
>> doing something sufficiently out of the ordinary that I'm confusing 
>> the implementation. Or do I just have a bug, and I've just been lucky?
>>
> 
> Did you go from NVIDIA to ATI..?
> 
> ATI cards are a lot more fussy about what they accept,
> but getting your program working on an ATI card will
> usually make the program more "correct".

3DLabs VX1 to ATI 9800. Much faster, but wrong results. :-)

--
Andy V

Andy V wrote:
> fungus wrote:
> 
>> Did you go from NVIDIA to ATI..?
>>
> 
> 3DLabs VX1 to ATI 9800. Much faster, but wrong results. :-)
> 

Well, I got the "to ATI" part right... :-)

Don't worry, a week from now your program will be a little
bit neater than it is today.


-- 
<\___/>          "To err is human, to moo bovine."
/ O O \
\_____/  FTB.    For email, remove my socks.

fungus wrote:

> Andy V wrote:
> 
>> fungus wrote:
>>
>>> Did you go from NVIDIA to ATI..?
>>>
>>
>> 3DLabs VX1 to ATI 9800. Much faster, but wrong results. :-)
>>
> 
> Well, I got the "to ATI" part right... :-)
> 
> Don't worry, a week from now your program will be a little
> bit neater than it is today.
> 
> 
Well, today it is working much, much better -- but I haven't started to 
change the code around yet.

--
Andy V