[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* James Turner -- Wednesday 06 April 2005 11:37: Bad news - I've had this change in my tree for a few months now, and it doesn't work right on OS-X So then add a #ifdef for OS-X around the resize event, so that it is simply ignored? Did you send a bug report to the SDL people? #ifdef OSX // or whatever the #define is case SDL_VIDEORESIZE: if (SDL_SetVideoMode(e.resize.w, e.resize.h, 16, VidMask) == 0) throw sg_throwable(string(Failed to set SDL video mode: ) + SDL_GetError()); if (WindowResizeHandler) (*WindowResizeHandler)(e.resize.w, e.resize.h); break; #endif m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* Melchior FRANZ -- Wednesday 06 April 2005 12:14: Did you send a bug report to the SDL people? Or the plib people? Anyway, we allow glut windows to be resized, and I wouldn't understand if we wouldn't allow it for SDL on all systems, just because of broken OSX or broken OSX support in plib. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 11:14, Melchior FRANZ wrote: So then add a #ifdef for OS-X around the resize event, so that it is simply ignored? Did you send a bug report to the SDL people? I think you misunderstand, it's not an SDL bug: *FlightGear is relying on assumption about how OpenGL implementations work that does NOT hold on OS-X, and may not hold on some Windows drivers, but which happens to hold in the common case on Windows, and apparently always holds on Linux* There are plenty of SDL + GL applications on the Mac that do re-sizing just fine, but they have the ability to initiate a vid-restart (as they correctly should on *every* platform, strictly speaking) when re-sized. Of course, we can certainly live without the feature on Mac - just be aware the fault lies with FG / PLIB for not providing an API that is somewhat important in real-world situations. I for one would love to be able to switch from full-screen mode to windowed while running, for example. HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* James Turner -- Wednesday 06 April 2005 12:28: Of course, we can certainly live without the feature on Mac - just be aware the fault lies with FG / PLIB for not providing an API that is somewhat important in real-world situations. I for one would love to be able to switch from full-screen mode to windowed while running, for example. So it's the glViewport() in FGRenderer::resize() that doesn't work with plib/fgfs on OSX? (It's certainly not window resizing on the SDL or GLUT level.) Is there a plib method to save all necessary resources before the viewport change and to restore them afterwards? Norman? :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 12:53, Melchior FRANZ wrote: Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's a suspicious comment in there: * WARNING, we need to make sure that the previous mode hasn't * already been freed by the video driver. What do we do in * that case? Should we call SDL_VideoInit() again? */ Would be nice if we could identify and fix the bug where it is, instead of removing a useful feature that is certainly *not* the bug. I'm going to restate the problem, just to be very clear. - When a window is resized, SDL (or GLUT) need to re-allocate the GL context. The SDL documentation explicitly mentions that SDL_SetVideoMode will be called again with new size, so a new context will definitely get created on the Mac. I'm putting aside any platform specific ways to modify existing contexts. - There is nothing (absolutely nothing) in the OpenGL spec about the sharing or lifetime of texture objects or displays lists across different contexts - logically they are completely separate. - The current FlightGear code assumes that display lists and textures are preserved across a context switch. - This has not been noticed for the past X years because it *so happens* that the Linux and stock Win32 implementations happen to implement the sharing behaviour between contexts, while OS-X does not. Both behaviours are completely valid and compliant implementations of the OpenGL spec. - Most (if I'm being bitchy, *good*) scene-graph / engine libraries have some kind of 'invalidate' button you can kick that makes them delete all their display lists / textures and reload them. This is what Unreal / Quake / etc are doing which you change full-screen-ness or many other graphics settings while they running, i.e a vid restart. - Making PLIB / FG support vid restarts would be a very good thing to do, but would be a lot of work and invasive. I would be happy to give it a go if I thought the patches would be accepted! - Until such a change is made, re-sizing the window is not going to work right on OS-X - We can live with this situation. But if there are any user bugs reported from Windows users with odd drivers about 'everything looking crazy after I resize the window', well, now you know :-) Regards, James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* James Turner -- Wednesday 06 April 2005 14:17: - Making PLIB / FG support vid restarts would be a very good thing to do, but would be a lot of work and invasive. I would be happy to give it a go if I thought the patches would be accepted! Sigh ... that's not so sure. - We can live with this situation. But if there are any user bugs reported from Windows users with odd drivers about 'everything looking crazy after I resize the window', well, now you know :-) OK, thanks for explaining the third time. I guess even I have fully understood this now. :-) I was just too eager to defend my SDL patch, and worried that the patch would simply get reverted. I think it would be a good idea to describe the problem on the plib list and ask if a fix would be accepted. (And be prepared to wait a few weeks for an answer. You may even have to repost the question until someone bothers to answer. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* Melchior FRANZ -- Wednesday 06 April 2005 13:19: So it's the glViewport() in FGRenderer::resize() that doesn't work with plib/fgfs on OSX? Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's a suspicious comment in there: * WARNING, we need to make sure that the previous mode hasn't * already been freed by the video driver. What do we do in * that case? Should we call SDL_VideoInit() again? */ Would be nice if we could identify and fix the bug where it is, instead of removing a useful feature that is certainly *not* the bug. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
