Bug 6941

Fixed.

I'm not sure changing glxgears.c is the right solution.  glxgears has been
running fine as-is on many drivers for many years.

It may be a driver bug.  Which driver are you using?

I'm using the r300 driver.

IIRC it was mentioned on IRC that this behaviour was a bug in glxgears that was
fixed in the monolithic tree. I had a look at that copy but couldn't find the
fix for this specific problem, so I gave it a try myself ;)

OK, so just one of the three gears is the wrong size?  Which one?  Maybe attach
a screenshot?

Created attachment 5655 [details]
Screenshot

No, the window just shows a section of the whole scene in closup (the lower
right part of the red gear).

Maybe it should be mentioned that this is WM specific to some degree; the best
way to reproduce it that I know of is to run glxgears with no WM running.

Brian, is it supposed to produce correct output without ever calling
glViewport() and friends?

That said, this isn't the fix I remember, which was just to call reshape()
during initialization I think.

Yes Michel, there should be no need to call glViewport during initialization
since the OpenGL spec says that the first time a new rendering context is bound
to a window, the context's viewport and scissor box should be initialized to
match the window size.

This is done in _mesa_make_current():

         if (newCtx->FirstTimeCurrent) {
            /* set initial viewport and scissor size now */
            _mesa_set_viewport(newCtx, 0, 0,
                               drawBuffer->Width, drawBuffer->Height);
	    _mesa_set_scissor(newCtx, 0, 0,
			      drawBuffer->Width, drawBuffer->Height );
            check_context_limits(newCtx);
         }

Tilman, can you set a breakpoint there and see if drawBuffer->Width and Height
are 300 (the initial window size)?

Yes, they are both set to 300.

OK, next I'd check that the r300's viewport state is getting set. 
r300UpdateWindow() should be getting called with the 300x300 viewport size prior
to drawing the first frame.

r300UpdateWindow() operates just fine. The bug is still present if I hardcode
the 4 VPT values to the ones that are being used when I resize the window (to
fix the rendering issue).

If you take any of the Mesa GLUT demos and comment-out the glViewport call, they
should still render properly, until you resize the window.  Maybe try that and
see if other programs show the problem...

Does it get called at all?
Iv seen various little bugs dealing with window updates happen on r300 in the past.
rmesa->state.depth.scale might also be worth checking.

Created attachment 5661 [details] [review]
Set initial projection/viewing transform

Michel pointed out another possibility to me.  If reshape() isn't getting
called before rendering (maybe because of no window manager to trigger
ConfigureNotify), we won't properly set the projection/viewing transformations.


Try this patch.

Aapo: Are you referring to r300UpdateWindow()? Yes, it's getting called.

Brian: Your patch works as well. Actually that's the same I did first, but I
thought calling reshape from the expose event handler was the more correct solution.

It sounds like the real problem is ConfigureNotify isn't always received when
the window first appears (depends on window manager).  Adding a call to
reshape() after init() fixes the problem.

I think we can close this bug now.

Mass version move, cvs -> git