On 6 Apr 2005, at 09:46, Erik Hofman wrote:
Modified Files: fg_os_sdl.cxx Log Message: Melchior FRANZ:
Make SDL window resizable; This exposes the same problem that many GLUT users have: resizing up may cause a temporary switch to software rendering if the card is low on memory. Resizing down again switches back to HW rendering. (KSFO is texture intensive, but there are no problems in LOWL, and elsewhere.) Less and less users will have the problem as cards become better, and it's no reason not to allow resizing altogether.
Bad news - I've had this change in my tree for a few months now, and it doesn't work right on OS-X, due to a fairly deep-rooted problem with PLIB / FlightGear - there doesn't seem to be a way to do a 'vid restart', i.e force every display list / buffer / texture to get deleted and reloaded.
This is really something that should be supported at the PLIB level, but, well, that's another story.
Anyway, the Linux GL implementation appears to re-use GL contexts upon re-size, but the OS-X sometimes tears them down and re-allocates them. When this happens, I get a very interesting looking, un-textured version of FlightGear; kinda retro but not usable. Incidentally, the OpenGL spec dodges this whole issue, but from porting various other pieces of GL code, the rule seems to be that Windows and Linux tend to re-use contexts (but some Windows drivers don't always), but the Mac drivers are very aggressive about throwing out contexts are starting again.
Anyway, the 'display lists and textures are valid across a context change' assumption is basically an unportable one.
BTW, this is also the reason it's hard to do a 'full-screen toggle' at runtime (which otherwise would be easy in SDL), or other graphics changing options. However, I had a look around the code and I'm pretty sure trying to make vid-restarts possible at this point would be quite invasive changes, so I didn't even bother to suggest it.
Ho hum, James
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
