if not: The drawn part of the GL view is not resized, but remains its original size, tied to the upper left corner of the window. The rest of the window fills with junk: fragmented bits from the screen buffer--the gears, neighboring windows. It's actually kind of fun to look at. The rendering in the view continues and does scale, but is positioned wrong (e.g. shows only the red gear in the upper left of the window when enlarged--it's shifting vertically in the opposite direction as it should to keep it centered). This is an app problem where glxgears isn't resizing the viewport on a window resize. Er, maybe, but glxgears is a quite standard app, that I have seen running on several X11 implementations (including X11 4.2 and 4.2.99 on OS X) and this is the first time I have seen such behaviour.
if not: The drawn part of the GL view is not resized, but remains its original size, tied to the upper left corner of the window. The rest of the window fills with junk: fragmented bits from the screen buffer--the gears, neighboring windows. It's actually kind of fun to look at. The rendering in the view continues and does scale, but is positioned wrong (e.g. shows only the red gear in the upper left of the window when enlarged--it's shifting vertically in the opposite direction as it should to keep it centered). This is an app problem where glxgears isn't resizing the viewport on a window resize.
if not: The drawn part of the GL view is not resized, but remains its original size, tied to the upper left corner of the window. The rest of the window fills with junk: fragmented bits from the screen buffer--the gears, neighboring windows. It's actually kind of fun to look at. The rendering in the view continues and does scale, but is positioned wrong (e.g. shows only the red gear in the upper left of the window when enlarged--it's shifting vertically in the opposite direction as it should to keep it centered).