From: Richard R. <sf...@ol...> - 2004-02-19 03:07:33
|
Currently, when you register glutDisplayFunc(), freeglut turns on the {window->State.Redisplay} flag. This isn't so bad for onscreen windows. It's a problem for offscreen windows, since you probably do not want an initial, automatic redisplay. But you have to register a display callback. I can't see any good reason to have the flag turned on even for onscreen windows, though, since onscreen windows will get various events (such as window creation) to force a redisplay. I want to completely remove this line (currently line 55 of freeglut_callbacks.c; the last line in the glutDisplayFunc() function). Is there any reason not to do remove this line? Or is it felt to be better to leave the offscreen windows the way that they are---with a forced redisplay call on creation, even if it is not always appropriate or desirable? (It may, in some cases, force the program to add extra logic to avoid a display that it is not prepared to work with. It may also be at the root of some problems that I think we've had reported about redisplay events happening too soon for regular windows; the more I look at it, the harder pressed I am to think why on Earth we want to make glutDisplayFunc() do an implicit glutPostRedisplay().) --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Steve B. <sjb...@ai...> - 2004-02-19 06:33:29
|
Richard Rauch wrote: > It's a problem for offscreen windows, since you probably do not want > an initial, automatic redisplay. But you have to register a display > callback. This comes back to my gut feeling that the whole concept of offscreen rendering areas being windows at all is fundamentally wrong. I can't imagine practical applications of offscreen rendering wanting any kind of callbacks at all. The most likely need is to be inside an ON-screen window redraw event callback - and to want to switch over to drawing into the off-screen window - then to use the contents in continuing to render the on-screen area. I still maintain that the best way to do this stuff is to have a hierarchy of class types (yes, I know this isn't a C++ program - but that doesn't stop you from thinking in an OOP way): Base class: A rendering area. Derived class #1: A window. Derived class #2: An off-screen rendering area. Then we think about what functionality belongs in the base class and what belongs in the derived classes. In this way, we would decide that event callbacks are ONLY applicable to 'Window' objects, also borders, titles and such....whilst 'becoming the current rendering context' would be an attribute of the base class. This elegantly removes any issues of window-like behaviour having to be disabled or artificially emulated for things like off-screen rendering areas that really are nothing like a window. This distinction is going to get ever more critical as OpenGL grows to allow rendering into vertex arrays and such like. All this effort to make off-screen areas behave like windows just screams: "I'm a horrible kludge". ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
From: Nigel S. <ni...@ni...> - 2004-02-19 13:19:50
|
> I can't imagine practical applications of offscreen rendering wanting > any kind of callbacks at all. So, could we simply resolve that offscreen "windows" never receive callbacks - fullstop? Nigel |
From: Steve B. <sjb...@ai...> - 2004-02-19 14:17:24
|
Nigel Stewart wrote: > >> I can't imagine practical applications of offscreen rendering wanting >> any kind of callbacks at all. > > > So, could we simply resolve that offscreen "windows" > never receive callbacks - fullstop? IMHO, Yes. Let's look at the callbacks: glutMouseFunc glutMotionFunc glutPassiveMotionFunc glutKeyboardFunc glutSpecialFunc glutKeyboardUpFunc glutSpecialUpFunc glutJoystickFunc glutSpaceballMotionFunc glutSpaceballRotateFunc glutSpaceballButtonFunc glutButtonBoxFunc glutDialsFunc glutTabletMotionFunc glutTabletButtonFunc glutEntryFunc glutMenuStateFunc glutMenuStatusFunc These all relate to peripheral input functions. However, they all require that the input is somehow directed to this window by the user. Since it's impossible for the user to give focus to something he can't see - none of these are ever going to apply to a pbuffer. glutReshapeFunc glutVisibilityFunc glutWindowStatusFunc Again, there is no way for the user to reshape or push/pop/move a pbuffer - so these are never needed. If the pbuffer can be reshaped under software control then that software can call the reshape function directly without freeglut getting in the way. glutOverlayDisplayFunc I doubt that we'll have implementations of pbuffers that even support overlays - so this isn't likely to be needed...but even if we did, the same arguments apply as to glutDisplayFunc glutTimerFunc glutIdleFunc These two are not window-specific - so they aren't relevent to this discussion. glutDisplayFunc This seems pointless. The only time it could ever be called is on startup or immediately following a glutPostRedisplay(). But that's simply not how pbuffers are used. Rendering them out of sync with the actual visible windows is pointless. You always want them to be rendered immediately and under program control - not in response to some other event in the windowing system. So - I don't see any callbacks that are remotely applicable to pbuffers. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
From: wave++ <wa...@yu...> - 2004-02-19 14:31:42
|
On Thu, Feb 19, 2004 at 08:10:58AM -0600, Steve Baker wrote: > So - I don't see any callbacks that are remotely applicable to pbuffers. Extremely good points. I agree. -- '(wave++ "Yuri D'Elia" "http://www.yuv.info/") |
From: Richard R. <sf...@ol...> - 2004-02-20 05:22:53
|
Hey, wave++. Can you test my guess that that bug that you were experiencing with SGI/Sun systems and too-early display callbacks is fixed by deleting line 55 of freeglut_callbacks.c? Here's the "diff -u" output: diff -u -r1.19 freeglut_callbacks.c --- freeglut_callbacks.c 19 Dec 2003 00:54:27 -0000 1.19 +++ freeglut_callbacks.c 20 Feb 2004 05:03:16 -0000 @@ -52,7 +52,6 @@ fgError( "Fatal error in program. NULL display callback not " "permitted in GLUT 3.0+ or freeglut 2.0.1+\n" ); SET_CALLBACK( Display ); - fgStructure.Window->State.Redisplay =3D GL_TRUE; } =20 /* (I've just committed this change since the line seems like a bug in its own right, and should never be required in normal operation. But my guess is that removing this line will solve your problem. No need, now, to mess about with glutMainLoopEvent() hacks.) --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: wave++ <wa...@yu...> - 2004-02-27 12:12:20
|
Sorry for repling so late... On Thu, Feb 19, 2004 at 11:16:55PM -0600, Richard Rauch wrote: > Can you test my guess that that bug that you were experiencing with SGI/Sun > systems and too-early display callbacks is fixed by deleting line 55 of > freeglut_callbacks.c? Here's the "diff -u" output: <...> > (I've just committed this change since the line seems like a bug in its > own right, and should never be required in normal operation. But my guess > is that removing this line will solve your problem. No need, now, to > mess about with glutMainLoopEvent() hacks.) Yup, actually a simple test on some applications seems to have fixed it. What was the point of setting Redisplay? I saw it the last time I was trying to debug, but without knowing the source I thought it was necessary. Reshape now is always called first. Actually, I've noted that keyboard/motion event can actually occur before the redisplay callback. Errors gone without the #warning directives. May I report some other minor warnings? :) cc-1164 c99: WARNING File = freeglut_cursor.c, Line = 151 Argument of type "unsigned char *" is incompatible with parameter of type "char *". cc-1552 c99: WARNING File = freeglut_cursor.c, Line = 104 The variable "error" is set but never used. cc-1164 c99: WARNING File = freeglut_init.c, Line = 631 Argument of type "GLint *" is incompatible with parameter of type "unsigned int *". cc-3604 c99: WARNING File = freeglut_gamemode.c, Line = 379 missing return statement at end of non-void function "fghChangeDisplayMode" <--- return is only inside the ifdef. some other warnings about unused stuff in joystick.c, but I assume is being worked on. Now, again on the gamemode (line 444). I would simply not move the window if the resolution change isn't supported. It's pointless to have a small window on the top-left corner. I'd ifdef it inside X_XF86VidModeSetViewPort. Also, I see the pointer grabbing feature has been implemented. Good job :). I only see a little problem with menus: the menus are still going outside the window, but you can no longer move the mouse over them :). Menus are still broken here however. I occasionally receive fatal badmatch errors from GLX. -- '(wave++ "Yuri D'Elia" "http://www.yuv.info/") |
From: Richard R. <sf...@ol...> - 2004-02-27 12:56:31
|
On Fri, Feb 27, 2004 at 01:09:40PM +0100, wave++ wrote: > Sorry for repling so late... >=20 > On Thu, Feb 19, 2004 at 11:16:55PM -0600, Richard Rauch wrote: > > Can you test my guess that that bug that you were experiencing with SGI= /Sun > > systems and too-early display callbacks is fixed by deleting line 55 of > > freeglut_callbacks.c? Here's the "diff -u" output: > <...> > > (I've just committed this change since the line seems like a bug in its > > own right, and should never be required in normal operation. But my gu= ess > > is that removing this line will solve your problem. No need, now, to > > mess about with glutMainLoopEvent() hacks.) >=20 > Yup, actually a simple test on some applications seems to have fixed it. Good. Glad to hear that. (^& I'll mark the bug report as "closed", then. > What was the point of setting Redisplay? I saw it the last time I was > trying to debug, but without knowing the source I thought it was > necessary. I haven't checked to see when it was committed or by whom. My guess is that calling it when the display callback was set was a kludge so that newly-created windows would get a redisplay. Most of the time, this is harmless because most of the time you set the window display callback right after asking GLUT to create the window. Apparently, due to timing, or sensitivity of the X server to such abuses, it fails for you, but works for some other cases. However, it seems to be a bug for your case. And if you set the redisplay function to a different function-pointer at a later time, you might be annoyed/surprised to get a bogus redisplay. (As I was annoyed/surprised to find it happening for offscreen windows.) This rings a bell from when I had just joined the project. I do seem to recall seeing a bug like that, and pointing it out. I possibly even suggested the kludge since at that time the freeglut_main.c file was a horrible mess and I didn't even try to read any more of the freeglut code than I absolutely had to. (Late last year, I caused window-creation to act like a ConfigureNotify event, which does effectively do a glutPostRedisplay(). That was possily the point at which this kludge became unnecessary.) > Reshape now is always called first. Actually, I've noted that > keyboard/motion event can actually occur before the redisplay callback. Hm. That's a bit weird. Was it possible with old GLUT? We postpone redraws and a few other events, so that only one is called (per window) per pass through the glutMainLoopEvent() function. But most events get dispatched immediately. I'm not sure that this is a real bug, and changing it would be a bit of a kludge. > Errors gone without the #warning directives. >=20 > May I report some other minor warnings? :) Sure. Nothing stops you from reporting them. (^& gcc on NetBSD/amd64 doesn't give me any warnings, last I checked. (Though for some reason, our configure script defaults to *not* enable heavy compiler warnings. Since the code is actually pretty clean at this point, and at least sometimes has been warning-free, I'm not sure why the default isn't to enable warnings.) [...] > some other warnings about unused stuff in joystick.c, but I assume is > being worked on. It wouldn't hurt to report them, unless there are a bunch of them. I'd also suggest reporting the warnings with a couple of lines of context, since the files may not look the same by the time someone gets around to dealing with them. > Now, again on the gamemode (line 444). I would simply not move the > window if the resolution change isn't supported. It's pointless to have > a small window on the top-left corner. I'd ifdef it inside > X_XF86VidModeSetViewPort. >=20 > Also, I see the pointer grabbing feature has been implemented. Good job > :). I only see a little problem with menus: the menus are still going > outside the window, but you can no longer move the mouse over them :). Grabbing for gamemode has been there, I think. Hasn't it? Unless something changed quite recently... (I don't subscribe to the CVS lists, but just checked the online archive. It probably is lagging a little behind reality...the last commit that it shows is on the 20th.) > Menus are still broken here however. I occasionally receive fatal > badmatch errors from GLX. That's not good. I've never seen that happen with menus, but the menus certainly need some work. Can you reliably produce it? Can you do this on an XFree86 system with a local X server? (I ask the latter because that's the easiest thing for me to test. A remote X server would be doable. Non-XFree86 servers would be a bit of a problem for me right now.) --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: wave++ <wa...@yu...> - 2004-02-27 15:56:55
|
On Fri, Feb 27, 2004 at 06:53:59AM -0600, Richard Rauch wrote: > This rings a bell from when I had just joined the project. I > do seem to recall seeing a bug like that, and pointing it out. > I possibly even suggested the kludge since at that time the > freeglut_main.c file was a horrible mess and I didn't even try > to read any more of the freeglut code than I absolutely had to. > (Late last year, I caused window-creation to act like a > ConfigureNotify event, which does effectively do a glutPostRedisplay(). > That was possily the point at which this kludge became unnecessary.) Heh, deja vu > > Reshape now is always called first. Actually, I've noted that > > keyboard/motion event can actually occur before the redisplay callback. > > Hm. That's a bit weird. Was it possible with old GLUT? I will check (switching from freeglut to glut is a bit a problem, as I changed some bits everywhere :)). > We postpone redraws and a few other events, so that only one is > called (per window) per pass through the glutMainLoopEvent() > function. But most events get dispatched immediately. > > I'm not sure that this is a real bug, and changing it would > be a bit of a kludge. I don't see any problem actually, unless someone expects to initialize some data for the input callbacks into the display one (which is bad anyway). Anyway, a reshape function on one of my programs takes some time (~10 sec), so if you actually move the mouse over the window before it finishes, you will receive input before the display. > > Menus are still broken here however. I occasionally receive fatal > > badmatch errors from GLX. > > That's not good. I've never seen that happen with menus, but the > menus certainly need some work. > > Can you reliably produce it? Can you do this on an XFree86 system > with a local X server? (I ask the latter because that's the easiest > thing for me to test. A remote X server would be doable. Non-XFree86 > servers would be a bit of a problem for me right now.) It's quite reproducible. The problem seems to be related with submenus. The example program "One" crashes consistently if you move into a submenu (it displays fine though). -- '(wave++ "Yuri D'Elia" "http://www.yuv.info/") |
From: Richard R. <sf...@ol...> - 2004-02-27 23:32:17
|
On Fri, Feb 27, 2004 at 04:54:14PM +0100, wave++ wrote: [...] > > > Menus are still broken here however. I occasionally receive fatal > > > badmatch errors from GLX. > > > > That's not good. I've never seen that happen with menus, but the > > menus certainly need some work. > > > > Can you reliably produce it? Can you do this on an XFree86 system > > with a local X server? (I ask the latter because that's the easiest > > thing for me to test. A remote X server would be doable. Non-XFree86 > > servers would be a bit of a problem for me right now.) >=20 > It's quite reproducible. The problem seems to be related with submenus. > The example program "One" crashes consistently if you move into a > submenu (it displays fine though). Hum. I have some old programs that use GLUT menus. With them, I noticed: 1 For some programs, menus do *not* ever go away. 2 If you have two windows with menus, it is possible to get both windws up at once. (Possibly this is what is confusing freeglut for the first problem?) 3 It is possible to crash my *X* server (screen goes black and I'm dropped back to the text console that I logged in on). This may or may not be menu-related. But it's very nasty. It feels menu-related, based on the interaction, but I can't be sure at this time. I think that the gamemode demo ("One") uses two or more windows with menus, doesn't it? --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Richard R. <sf...@ol...> - 2004-02-19 15:26:42
|
On Thu, Feb 19, 2004 at 08:10:58AM -0600, Steve Baker wrote: > Nigel Stewart wrote: > > > >>I can't imagine practical applications of offscreen rendering wanting > >>any kind of callbacks at all. > > > > > > So, could we simply resolve that offscreen "windows" > > never receive callbacks - fullstop? First, this is tangential to the issue. The issue is that we have a bug in glutDisplayFunc(). Even if we did not have GLUT_OFFSCREEN in the code, we would still have a bug in glutDisplayFunc(). > IMHO, Yes. >=20 > Let's look at the callbacks: >=20 > glutMouseFunc glutMotionFunc glutPassiveMotionFunc glutKeyboardFunc > glutSpecialFunc glutKeyboardUpFunc glutSpecialUpFunc glutJoystickFunc Um, I don't know about the Spaceball, ButtonBox, or Dials, but glutJoysstic= kFunc is *not* dependant upon having an onscreen window. These events do *not* c= ome in through the window event queue. There is no relation to the "input focus" for joysticks. So the joystick, at least, makes as much sense for offscreen as for onscree= n. I don't suppose that you're arguing that Joystick support should be removed, right after John imported the new joystick support code? Do I have to spell out an explicit example using OpenGL before you can imagine an application for this? Does it matter whether you can imagine a use for it? Okay, here's an easy one: Data is acquired to some database in more or less realtime. At the click of a joystick button, the data is rendered using OpenGL drawing to an offscreen buffer and pumped out a network socket as a .PNG image visualization. There's no need for an onscreen window, anywhere. It would be a "horrible kludge" to add one. (Where is the image sent? What's the source of the data for the database? What's the interpretation of the image? I trust that you can fabricate plausible sample answers to those questions. Conventional input is obviously not used because the computer is running headless... It's not that hard to come up with this, is it?) But, IMHO, lack of ability to imagine a use for a feature is not a good reason to remove it. Not when it's work to remove and having it is free and internally consistant. And it works quite well, right now. [...] > glutReshapeFunc glutVisibilityFunc glutWindowStatusFunc >=20 > Again, there is no way for the user to reshape or push/pop/move a > pbuffer - so these are never needed. If the pbuffer can be reshaped Resizing would be trivial to add, but GLUT never guarantees any window resizes, so I decided not to implement it at the first pass. But, it really doesn't matter whether pbuffers are used to realize the offscreen windows. Pixmaps are presently used; they do not resize on their own, but supporting resizing would be easy. Pushing/popping/moving is entirely relavent for subwindows. Though there is no present support for actually creating offscreen subwindows, the logical framework is there. The case for offscreen subwindows is just stubbed out. There is nothing stopping anyone from adding the 20 or 30 requisite lines to make them work, should the need arise. > under software control then that software can call the reshape function > directly without freeglut getting in the way. We are talking about offscreen windows. OpenGL doesn't know how to manipulate them. Resizing inside of freeglut would be trivial to add if desired, though without subwindow support in general, it didn't seem worth the bother. All well-written programs will not assume that resizing automatically works (GLUT is quite clear on that point), so ignoring resize requests is not technically a bug. So, freeglut isn't "in the way". It *is* the way. If you really want offscreen windows to have only the main point in common with windows (a drawable surface), then you should seriously rethink whether the GLUT notion of a "window id" and the "current window" can be maintained. It is bad design to use things like glutSetWindow() to set the non-window offscreen drawing area as current, if you are not prepared to think of, and use, the target as a window. =2E..of course, that will break GLUT compatibility rather heavily. IMHO the only clean way out is the current API: Call it a window and treat it as one, in at least a minimalist sense. That's what Nigel's suggested API, and my implementation, do. [...] > glutDisplayFunc >=20 > This seems pointless. The only time it could ever be called is on > startup or immediately following a glutPostRedisplay(). But that's Not true. If it were true, there would be no problem. It should be true. Seeing that people have only engaged in tangential conversation, I conclude that there is no disagreement about the bug itself. I propose to fix this bug and ask the SGI/Sun guy if his problems are solved by the fix. I probably shouldn't have mentioned it, seeing that it has set of a proverbial firestorm over a one-line bug that is hardly related to the discussion that has ensued. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Steve B. <sjb...@ai...> - 2004-02-19 16:18:05
|
Richard Rauch wrote: > Um, I don't know about the Spaceball, ButtonBox, or Dials, but glutJoysstickFunc > is *not* dependant upon having an onscreen window. These events do *not* come in > through the window event queue. So if they aren't aimed at a specific window, then they are like timer callbacks or the idle callback in that they'll still happen if you don't have any windows present. > Do I have to spell out an explicit example using OpenGL before you > can imagine an application for this? Does it matter whether you > can imagine a use for it? Okay, here's an easy one: Data is acquired > to some database in more or less realtime. At the click of a > joystick button, the data is rendered using OpenGL drawing to an > offscreen buffer... Sure - but if the joystick callback will happen anyway, then having the offscreen area NOT be a-kind-of window won't prevent that from working. What my suggested mechanism WOULD stop from working would be to use a mouse click or a keyboard keystroke to do what you suggest. However, since there is no way for the end user to impart keyboard or mouse focus on the off-screen buffer, that won't work with your mechanism either. So this is bogus. The trick with the joystick will work with both schemes - and if you need to use the mouse or keyboard to do interaction then the end user has to have a visible window to interact *with* - and your example STILL works either way. >> glutReshapeFunc glutVisibilityFunc glutWindowStatusFunc >> >> Again, there is no way for the user to reshape or push/pop/move a >> pbuffer - so these are never needed. If the pbuffer can be reshaped > > > Resizing would be trivial to add, but GLUT never guarantees any window > resizes, so I decided not to implement it at the first pass. But, it > really doesn't matter whether pbuffers are used to realize the offscreen > windows. Pixmaps are presently used; they do not resize on their own, > but supporting resizing would be easy. But the resize callback is only called when the user clicks on a resize widget on the window decorations. Since off-screen buffers neither have those decorations, nor can be clicked on, the concept of a resize *CALLBACK* is pointless since it'll never be called. I agree that resizing of an off-screen window is something that should be allowed - but that's orthogonal to this question. > Pushing/popping/moving is entirely relavent for subwindows. ...but there are no subwindows for pbuffers (nor should there be IMHO), so that's irrelevent. > If you really want offscreen windows to have only the main point > in common with windows (a drawable surface), then you should seriously > rethink whether the GLUT notion of a "window id" and the "current window" > can be maintained. It is bad design to use things like glutSetWindow() > to set the non-window offscreen drawing area as current, if you are not > prepared to think of, and use, the target as a window. I would implement glutSetDrawingArea - which would accept either a window handle or an off-screen rendering area handle. glutSetWindow would simply call glutSetDrawingArea for backwards compatibility - and probably 'assert' if it were called with an off-screen handle. > ...of course, that will break GLUT compatibility rather heavily. Not in the slightest. > IMHO the only clean way out is the current API: Call it a window and > treat it as one, in at least a minimalist sense. That's what Nigel's > suggested API, and my implementation, do. But now you have to go and implement resize, subwindows, glutPostRedisplay and a bunch of other junk *just* so that your documentation comes out clean and you can apply any window function to any window (including the off-screen ones). > glutDisplayFunc >> >> This seems pointless. The only time it could ever be called is on >> startup or immediately following a glutPostRedisplay(). But that's > Not true. If it were true, there would be no problem. It's true (or at least *should* be true) for off-screen windows. I don't dispute that it could be called at other times for regular windows. > I probably shouldn't have mentioned it, seeing that it has set of a > proverbial firestorm over a one-line bug that is hardly related to > the discussion that has ensued. As should be clear by now - I'm not arguing about the one-line bug. I'm saying that the API we seem to be rushing into is ill-considered and should be re-thought before we invest any more effort in that direction - and CERTAINLY before we make any kind of release and get users depending on it. In the end, this is about making a clean API without nasty little exceptions. It's a matter of taste - not a matter of how it's implemented. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
From: Nigel S. <ni...@ni...> - 2004-02-20 02:43:04
|
> In the end, this is about making a clean API without nasty little > exceptions. It's a matter of taste - not a matter of how it's > implemented. It is rather early to insist on nailing down the API for such a new feature. I can see problems with both directions - 1. "Offscreen Window" + Minimal impact on API + Minimal impact to application code + One OpenGL context per window, subwindow or offscreen window - Event model awkwardness - Subwindow awkwardness 2. "Rendering Area" + Clear distinction between windows and pure OpenGL contexts + Simplicity of implementation + Orthogonal API documentation - Awkward useage by applications - Removes the possibility of subwindow support, etc... I remain on the "offscreen window" side for the reason that having different kinds of windows is tidier conceptually than seperate windows and rendering areas. There are already windows and subwindows, I don't see adding one additional variety of window as a major problem. It retains the window/GL context relationship, at the very least. On the event side, I think an offscreen window should support a "reasonable subset" of the normal callback interface. Open, close, draw, resize. But, it would be normally expected that offscreen windows are manually created and explicitly drawn into to. I think it would be handy to do command-line based regression testing without major code changes for utilising offscreen rendering. > handle = glutCreateRenderingArea ( ...whatever... ); > glutDestroyRenderingArea ( handle ) ; > glutMakeCurrentRenderingArea ( handle ) ; > > This is very simple to explain, understand, document, etc. It is actually less clear in this case that a RenderingArea is distinct from a regular window and is a purely offscreen entity. >> It is bad design to use things like glutSetWindow() >> to set the non-window offscreen drawing area as current, if you are not >> prepared to think of, and use, the target as a window. If it turns out to be _convenient_ to treat it as a regular window, rather than dealing with a special API, why insist on being a non-window? > But now you have to go and implement resize, subwindows, glutPostRedisplay > and a bunch of other junk *just* so that your documentation comes out clean > and you can apply any window function to any window (including the > off-screen ones). So, let's see how the documentation actually turns out to be: ------------------------------------------------------------- GLUT_OFFSCREEN The following events are not applicable to an offscreen window. FreeGLUT will not call the following callbacks: glutMouseFunc glutMotionFunc glutPassiveMotionFunc glutKeyboardFunc glutSpecialFunc glutKeyboardUpFunc glutSpecialUpFunc glutJoystickFunc glutSpaceballMotionFunc glutSpaceballRotateFunc glutSpaceballButtonFunc glutButtonBoxFunc glutDialsFunc glutTabletMotionFunc glutTabletButtonFunc glutEntryFunc glutMenuStateFunc glutMenuStatusFunc glutOverlayDisplayFunc The following optional events are supported by offscreen windows, but are optional: glutDisplayFunc glutReshapeFunc glutVisibilityFunc glutWindowStatusFunc > I'm saying that the API we seem to be rushing into is ill-considered > and should be re-thought before we invest any more effort in that > direction - and CERTAINLY before we make any kind of release and get > users depending on it. I would say that we have an obvious difference of opinion and ought to defer finalising the API until we have had an opportunity to experiment and address the issues that arise. There is no rush here, apart from the pressure to do things according to the preconceptions of one contributor. Nigel |
From: Richard R. <sf...@ol...> - 2004-02-20 06:28:45
|
On Thu, Feb 19, 2004 at 09:36:27PM -0500, Nigel Stewart wrote: [...] > 1. "Offscreen Window" > =09 > + Minimal impact on API > + Minimal impact to application code > + One OpenGL context per window, subwindow or offscreen window Aside: Sharing contexts for offscreen works the same as with sharing between windows. There appears to be freeglut code to try to make that happen at least on UNIX_X11, but I haven't actually tried to exploit it for on- or offscreen. > - Event model awkwardness > - Subwindow awkwardness >=20 > 2. "Rendering Area" >=20 > + Clear distinction between windows and pure OpenGL contexts > + Simplicity of implementation =2E..I'm not sure that simplicity is a virtue of Rendering Areas. I think that simplicity of implementation is a close call, and am not prepared to say one or the other is simpler. Rendering areas look pretty simple, but offscreen windows have proven to be very simple. [...] > So, let's see how the documentation actually turns out to be: > ------------------------------------------------------------- >=20 > GLUT_OFFSCREEN >=20 > The following events are not applicable to an offscreen window. > FreeGLUT will not call the following callbacks: >=20 > glutMouseFunc glutMotionFunc glutPassiveMotionFunc glutKeyboardFunc > glutSpecialFunc glutKeyboardUpFunc glutSpecialUpFunc glutJoystickFunc I would argue that input devices that do not rely upon the focus (notably joysticks, but perhaps also spaceballs, dials, etc.) should be available to offscreen windows. The concept in my mind for "offscreen windows" is one of a window that has been dragged off to the side or buried. It would still receive joystick events, so a GLUT_OFFSCREEN should, too. [...] > >I'm saying that the API we seem to be rushing into is ill-considered > >and should be re-thought before we invest any more effort in that > >direction - and CERTAINLY before we make any kind of release and get > >users depending on it. >=20 > I would say that we have an obvious difference of opinion and > ought to defer finalising the API until we have had an > opportunity to experiment and address the issues that arise. > There is no rush here, apart from the pressure to do things Agreed, there is no rush. A sample implementation is available. That's all. No one should count on the experimental feature remaining unchanged, though it is available to play with. Presumably *some* kind of offscreen rendering will be available in the future, whether it is the current API, Steve's RenderingArea API, or some third way out. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Steve B. <sjb...@ai...> - 2004-02-20 23:42:15
|
Richard Rauch wrote: > I would argue that input devices that do not rely upon the focus (notably > joysticks, but perhaps also spaceballs, dials, etc.) should be available > to offscreen windows. Yeah - they have zero ties to the any kind of window because 'traditionally' these devices do not have window focus. No matter what, you'd be able to use those. Also timer and idle callbacks should still function...those too don't relate to any specific window. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
From: Richard R. <sf...@ol...> - 2004-02-21 00:09:31
|
On Fri, Feb 20, 2004 at 05:34:17PM -0600, Steve Baker wrote: > Richard Rauch wrote: >=20 > >I would argue that input devices that do not rely upon the focus (notably > >joysticks, but perhaps also spaceballs, dials, etc.) should be available > >to offscreen windows. >=20 > Yeah - they have zero ties to the any kind of window because 'traditional= ly' > these devices do not have window focus. No matter what, you'd be able to > use those. Perhaps I misunderstood you, then. I thought that you meant to zero out all window-based (in the GLUT sense) callbacks, or otherwise disable them, for offscreen displays. Since GLUT binds Joystick events on a per-window basis, I thought that you favored killing joysticks in that case. So, do you want to split the window-based callbacks into two sets? One that works for onscreen windows, and one that works for any display type? My only immediate use for this is really within bounds of your "rendering area" proposal. But I think that there is real value to maintaining the windowness of offscreen objects, to a reasonable extent. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Steve B. <sjb...@ai...> - 2004-02-21 00:44:18
|
Richard Rauch wrote: > Perhaps I misunderstood you, then. I thought that you meant to zero out all > window-based (in the GLUT sense) callbacks, or otherwise disable them, for > offscreen displays. Since GLUT binds Joystick events on a per-window basis, > I thought that you favored killing joysticks in that case. OK - I *still* don't think joystick events are tied to any particular window. That would be a meaningless thing to do since X doesn't tell us which window the Joystick event was intended for (there is no "Joystick focus") - and in fact, our joystick reader doesn't even *use* Xlib functions. So: *IF* Joystick callbacks are somehow kludged to be window-specific then I regard that as a bug we should fix. So given that joystick functions either are not or shortly will not be window-specific, they have no bearing on the pbuffer debate. If for some arcane reason the somehow have to be window-specific then they should not work in pbuffers because then they are exactly like mouse and keyboard events which also cannot work with pbuffers. > So, do you want to split the window-based callbacks into two sets? One > that works for onscreen windows, and one that works for any display type? They are already split in that way. There is no per-window idle callback for example (because how do you know which window is the idle one?!?). ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
From: Richard R. <sf...@ol...> - 2004-02-21 06:57:31
|
On Fri, Feb 20, 2004 at 06:36:47PM -0600, Steve Baker wrote: > Richard Rauch wrote: [...] > OK - I *still* don't think joystick events are tied to any particular=20 > window. > That would be a meaningless thing to do since X doesn't tell us which win= dow The events are generated by freeglut by examining the window structure to see when the event is supposed to happen (for that window). [...] > So: >=20 > *IF* Joystick callbacks are somehow kludged to be window-specific then I > regard that as a bug we should fix. It's hard to change something that's ingrained like that. Or, rather, easy to change but you know that someone's going to cry bloody murder because they depend upon the current window being set, or because they rely on the fact that changing a joystick binding for a window wipes out the old one (but you can have distinct joystick handlers for each window). The GLUT docs for SGI device input speak about the "current window", I believe, so Joysticks were probably just following that model. > So given that joystick functions either are not or shortly will not be > window-specific, they have no bearing on the pbuffer debate. >=20 > If for some arcane reason the somehow have to be window-specific then they > should not work in pbuffers because then they are exactly like mouse and > keyboard events which also cannot work with pbuffers. They are window specific only in that freeglut chose to so associate them. But they are not affected by the focus in any way shape or form. If, with your 10 years of experience with GLUT, feel that it is natural for joysticks to *not* be bound by a window, imagine the feeling of the poor fellow in my example who doesn't want an onscreen window, but does want OpenGL rendering offscreen and joystick support. He'll say that it's "bizarre" or "arcane". He'll swear at freeglut. He'll renew his library card and go to the library to look up new 4-letter words to scream at his computer. (^& > >So, do you want to split the window-based callbacks into two sets? One > >that works for onscreen windows, and one that works for any display type? >=20 > They are already split in that way. There is no per-window idle callback > for example (because how do you know which window is the idle one?!?). No, they are not split "that way". Presently, you have global events and you have window events. If we keep joysticks sensibly available for offscreen (and perhaps other non-focused input events), we will be splitting the window events into two classes: Focused, and unfocused. Up to now, freeglut has not made this distinction, nor can applications make the distinction. (That would be three classes of events, when you include global events that are not bound to windows.) If we use the same internal structure for offscreen areas/windows as for onscreen, we get joysticks for free. We get glutPostRedisplay() for free. We can get reshape events at virtually no cost should we so desire. And events that *can't* happen offscreen never happen, so there's no harm for those having event handlers registered if it makes the client application feel warm and fuzzy. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Richard R. <sf...@ol...> - 2004-02-20 05:05:36
|
On Thu, Feb 19, 2004 at 10:11:36AM -0600, Steve Baker wrote: > Richard Rauch wrote: >=20 > >Um, I don't know about the Spaceball, ButtonBox, or Dials, but=20 > >glutJoysstickFunc > >is *not* dependant upon having an onscreen window. These events do *not= *=20 > >come in > >through the window event queue. >=20 > So if they aren't aimed at a specific window, then they are like timer=20 Not aimed by the user, but aimed by the API. We can't readily go back and undo that, can we? Idle and timer callbacks are not bound to windows, that's true, which is why I didn't take exception to them. > >Do I have to spell out an explicit example using OpenGL before you > >can imagine an application for this? Does it matter whether you > >can imagine a use for it? Okay, here's an easy one: Data is acquired > >to some database in more or less realtime. At the click of a > >joystick button, the data is rendered using OpenGL drawing to an > >offscreen buffer... >=20 > Sure - but if the joystick callback will happen anyway, then having It won't happen unless you have a window to bind the joystick to. Offscreen windows offer that scaffolding. [...] > What my suggested mechanism WOULD stop from working would be to use > a mouse click or a keyboard keystroke to do what you suggest. As you say, this is irrelavent since any window that doesn't get input (e.g., behind another window, offscreen, etc.) won't get mouse or keyboard events. I don't see what this has to do with the matter at all. I didn't mention using mouse or keyboard input, so you can't be refuting any point that I made, I think. [...] > So this is bogus. The trick with the joystick will work with both > schemes - and if you need to use the mouse or keyboard to do interaction The "trick" with the joystick only works if you have a window to register the callback with. With your scheme, if the program does not have an onscreen window, it won't work. And not having an onscreen window for the joystick-reading application *was* kind of in there. Adding an onscreen window just for the joystick would not be all that friendly. > >>glutReshapeFunc glutVisibilityFunc glutWindowStatusFunc > >> > >> Again, there is no way for the user to reshape or push/pop/move a > >> pbuffer - so these are never needed. If the pbuffer can be reshaped > > > > > >Resizing would be trivial to add, but GLUT never guarantees any window > >resizes, so I decided not to implement it at the first pass. But, it > >really doesn't matter whether pbuffers are used to realize the offscreen > >windows. Pixmaps are presently used; they do not resize on their own, > >but supporting resizing would be easy. >=20 > But the resize callback is only called when the user clicks on a resize > widget on the window decorations. Since off-screen buffers neither have A resize under program control generates the callback as well. (GLUT docs are quite specific that you have to wait on the callback before you can rely upon the resize having had effect. The window manager may interfere with your attempt, and modify or reject the request. Even ignoring the window manager's interference, the request can be handled asynchronously since X is a network protocol.) So, to correct the above: The resize callback should be called whenever your window changes size---no matter why it changed size. > those decorations, nor can be clicked on, the concept of a resize *CALLBA= CK* > is pointless since it'll never be called. Not at present, since resizing is not supported. It would be easy to add. Then just do what the window system/manager would do and tell yourself that the window needs to be resized. (This is a boolean flag in the window state, BTW. It will get swept up during fgDisplayAll().) > I agree that resizing of an off-screen window is something that should > be allowed - but that's orthogonal to this question. > > >Pushing/popping/moving is entirely relavent for subwindows. >=20 > ...but there are no subwindows for pbuffers (nor should there be IMHO), > so that's irrelevent. Then the absense of subwindows---the sole weakness of the "offscreen is a window" scheme---is not an issue. > >If you really want offscreen windows to have only the main point > >in common with windows (a drawable surface), then you should seriously > >rethink whether the GLUT notion of a "window id" and the "current window" > >can be maintained. It is bad design to use things like glutSetWindow() > >to set the non-window offscreen drawing area as current, if you are not > >prepared to think of, and use, the target as a window. >=20 > I would implement glutSetDrawingArea - which would accept either a > window handle or an off-screen rendering area handle. glutSetWindow > would simply call glutSetDrawingArea for backwards compatibility - and > probably 'assert' if it were called with an off-screen handle. Asserts shouldn't be used for runtime checking or client abuse checking, I think. But that's been hashed out before. s/assert/if/. So, you can have the "current window" set to one thing, for things like adding menus, while the current drawing area is set to something else? I think that that's a bad idea. Or would glutSetDrawingArea() invalidate the current window setting? We had a thread a ways back about whether it was kosher to assume that there was always a current window... As I said in the other branch, this seems bad either way you slice it. [...] > >IMHO the only clean way out is the current API: Call it a window and > >treat it as one, in at least a minimalist sense. That's what Nigel's > >suggested API, and my implementation, do. >=20 > But now you have to go and implement resize, subwindows, glutPostRedisplay > and a bunch of other junk *just* so that your documentation comes out cle= an (blink) Resize is pretty easy. 10 minutes. I postponed it because it didn't seem important as a first cut and is technically never required. Subwindows: We agree that those aren't problems for now. To the extent that I care about them, I can produce a satisfactory handling. To the extent th= at you seem to care about them, they can be blown off forever. Let's drop that sideline. glutPostRedisplay "and a bunch of other *junk*": I have NO IDEA what you are talking about here. Everything else Just Works. Can you please point to what needs to be re-implemented, other than resize? > and you can apply any window function to any window (including the=20 > off-screen > ones). It already works. Basically, since subwindows are not supported, the functions just quietly ignore the requests as generally irrelavent (or, in the case of resizing, at least legally ignorable). > > glutDisplayFunc > >> > >> This seems pointless. The only time it could ever be called is on > >> startup or immediately following a glutPostRedisplay(). But that's >=20 > >Not true. If it were true, there would be no problem. >=20 > It's true (or at least *should* be true) for off-screen windows. It should be true for onscreen ones, too. But it's not. I'm talking about a bug in the code here. > >I probably shouldn't have mentioned it, seeing that it has set of a > >proverbial firestorm over a one-line bug that is hardly related to > >the discussion that has ensued. >=20 > As should be clear by now - I'm not arguing about the one-line bug. Then I'll fix that, at least. The bug is orthogonal to the API issue. > I'm saying that the API we seem to be rushing into is ill-considered > and should be re-thought before we invest any more effort in that > direction - and CERTAINLY before we make any kind of release and get > users depending on it. It was marked as experimental in the commit. I have nothing against replacing it with something better, but since discourse on the API seemed to be winding down, and Nigel's suggested API looked like a pretty good first approximation, and since things tend to languish without implementation sometimes, I went ahead and did it. I see no problem with addressing general warts and bugs that this feature brings to light in freeglut. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Steve B. <sjb...@ai...> - 2004-02-21 00:05:56
|
Richard Rauch wrote: > On Thu, Feb 19, 2004 at 10:11:36AM -0600, Steve Baker wrote: > >>Richard Rauch wrote: >> >> >>>Um, I don't know about the Spaceball, ButtonBox, or Dials, but >>>glutJoysstickFunc >>>is *not* dependant upon having an onscreen window. These events do *not* >>>come in >>>through the window event queue. >> >>So if they aren't aimed at a specific window, then they are like timer > > > Not aimed by the user, but aimed by the API. We can't readily go back > and undo that, can we? I don't understand how the API sends a particular joystick event to a particular window? With (for example) keyboard events, the event goes to whichever window has focus. For purely historical reasons, Joysticks aren't given focus - so they don't relate to any particular window. > It won't happen unless you have a window to bind the joystick to. Eh? Really? I can't read the joystick without having a window open? If that's true, it's a serious problem. If these events are tied to windows (like mouse and keyboard events) then tell me what happens if you have two windows open. How the heck does freeglut know which one to send the Joystick event to? I don't think it works like you seem to think it does. >>those decorations, nor can be clicked on, the concept of a resize *CALLBACK* >>is pointless since it'll never be called. > > Not at present, since resizing is not supported. It would be easy > to add. Then just do what the window system/manager would do and > tell yourself that the window needs to be resized. (This is a > boolean flag in the window state, BTW. It will get swept up during > fgDisplayAll().) That completely sucks. You are saying that if I want a differently sized off-screen area and ask freeglut to do it - then the rendering area won't change size immediately? That's unusable. Consider a typical application of pbuffers...rendering the view through a mirror. You are rendering your scene to a regular window...sometime in the culling and drawing phase, I come across a mirror hanging on the wall. At this point, I want to create resize my handy off-screen window to the approximate dimensions of the mirror and render the scene from a point behind the mirror. Then I tell the pbuffer to become a texture map and render that into the mirror polygon in the main window. If I have to resize the window the frame BEFORE I need it, then my only option is to create a pbuffer that's larger than the largest possible mirror and never resize it. Yuk! What a waste! (In retrospect, I could come up with better examples than that - but this one will do). If pbuffers are not resizable for some reason then I'll need to create a new one each time and delete it again at the end of the frame...but if everything goes through the same freeglut mechanism, I'm betting you'll tell me that I can't use my pbuffer immediately after I create it since you may not create it until sometime after I return from my render callback. That right there is the death-knell of treating pbuffers as Windows. Pbuffers are things I need *NOW* not at some time in the indefinite future. Operations on them utterly MUST happen immediately or they are practically useless. Since X doesn't allow windows to be created instantly, they cannot have that immediacy - hence pbuffers are mot definitely not windows and windows are most definitely not pbuffers. > Or would glutSetDrawingArea() invalidate the current window setting? Yes. You can't meaningfully have two rendering areas open at the same time. freeglut could automatically 'push' the current window id onto a stack - but then we'd need a "glutPopDrawingArea" - and that's getting messy. Since there is already a glutGetWindow, the application can easily implement pushing and popping - or any other kind of mechanism. > It was marked as experimental in the commit. I have nothing against > replacing it with something better, but since discourse on the API > seemed to be winding down, and Nigel's suggested API looked like a pretty > good first approximation, and since things tend to languish without > implementation sometimes, I went ahead and did it. I understand - and it has been useful in firming up the concepts. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
From: Richard R. <sf...@ol...> - 2004-02-21 01:22:11
|
On Fri, Feb 20, 2004 at 05:58:27PM -0600, Steve Baker wrote: [...] > >Not aimed by the user, but aimed by the API. We can't readily go back > >and undo that, can we? >=20 > I don't understand how the API sends a particular joystick event to a > particular window? With (for example) keyboard events, the event goes Joysticks in GLUT work on timers. They poll at regular intervals. But they are bound to windows. [...] > If that's true, it's a serious problem. If these events are tied to > windows (like mouse and keyboard events) then tell me what happens > if you have two windows open. How the heck does freeglut know which > one to send the Joystick event to? As I recall the joystick support on the window-handling side, every window has a highwater mark for the next joystick event. This is given in msecs. If the highwater is past, the joystick is read and the event is reported on the window-based callback. A few months ago, I proposed to change that to use real GLUT timers, which would simplify some of the code, and (especially now that the timer list is sorted and that fact is exploited) would greatly speed debug-tracing of the code. This got put on a back burner as I was dealing with more serious bugs at the time. The current code walks the tree of windows to dispatch joystick events. Don't look at me, I didn't write it. I only know that it's been like that since before I came to the project. (^& > I don't think it works like you seem to think it does. I'm pretty sure that it does. However, I'm happy to go back and review the code. Do you have a suggestion of where I should start, to clarify my understanding? In the meantime, I suggest that you look at freeglut_main.c, specifically: fghCheckJoystickPolls() fghcbCheckJoystickPolls() =2E..and also: freeglut_joystick.c::fgJoystickPollWindow() I think that you will at least agree that the code sure looks like it does what I said it does, from those functions. > >>those decorations, nor can be clicked on, the concept of a resize=20 > >>*CALLBACK* > >>is pointless since it'll never be called. > > > >Not at present, since resizing is not supported. It would be easy > >to add. Then just do what the window system/manager would do and > >tell yourself that the window needs to be resized. (This is a > >boolean flag in the window state, BTW. It will get swept up during > >fgDisplayAll().) >=20 > That completely sucks. You are saying that if I want a differently > sized off-screen area and ask freeglut to do it - then the rendering > area won't change size immediately? GLUT is quite clear that you can never count on this for windows. I was in "window paradigm mode". (^& But, since the reshape function doesn't provide any way to determine if it succeeded (what if you ask for 1e6 x 1e6 pixels? don't tell me that you can support *that* for offscreen rendering!). The callback is the only way to know if the call succeeded. For unamanaged displays (subwindows, offscreen), if the request is resaonable, you can probably just assume that it worked, if you can't wait. Your rendering commands should still go through the same queue, or else stall for the queue, so you don't really need to know when the command gets through. [...] > Consider a typical application of pbuffers...rendering the view through > a mirror. >=20 > You are rendering your scene to a regular window...sometime in the cullin= g=20 > and > drawing phase, I come across a mirror hanging on the wall. >=20 > At this point, I want to create resize my handy off-screen window to the= =20 > approximate > dimensions of the mirror and render the scene from a point behind the=20 [...] > to create a pbuffer that's larger than the largest possible mirror and=20 > never resize > it. Yuk! What a waste! If you are reaallocating the memory every little bit, that's also wasteful. Memory (de)allocation can be expensive. Also, if you allocate it as large as you want, in advance, then you know you will have the resources for it. (Just use a smaller viewport if you don't need the full size). If you reallocate it on-demand, you can fragment your memory (imagine several of these buffers). You also may lose significant time while the memory manager (wherever the buffers are held) attempts to merge memory chunks and search for a large enough memory chunk for the new request. Resizing seemed like a Nice Thing, but hardly essential. I kept the experimental implementation to the bare-bones essentials. > (In retrospect, I could come up with better examples than that - but this= =20 > one will do). >=20 > If pbuffers are not resizable for some reason then I'll need to create a= =20 > new one each > time and delete it again at the end of the frame...but if everything goes= =20 You could delete it at every pass. I wouldn't. I'd use a highwater mark and only reallocate if required. (I did intend to add resizing support, but was keeping the experimental code minimal.) If you know your max required resolution, you could also just preallocate. It does have its virtues, when you are sure of your needs. You could even do something adaptive, so that a buffer that is rarely used shrinks over time, freeing resources after it is no longer used, but holding them "for a while". > through the > same freeglut mechanism, I'm betting you'll tell me that I can't use my= =20 > pbuffer immediately > after I create it since you may not create it until sometime after I retu= rn=20 > from my render > callback. > > That right there is the death-knell of treating pbuffers as Windows. Hm. This is a problem. At least, it is *formally* a problem. In practice, the rendering area is available immediately I believe (at least w.r.t. the OpenGL/GLX rendering command queue), but the formalism of GLUT callbacks are in principle held off. Options: * Well, it is in effect an unmanaged window. As long as the dimensions are reasonable, you might just assume that it works. (Or freeglut could blow up if it fails, which is graceless.) * Use destroy/create when you really do need to resize the buffer. This would prevent freeglut from possibly doing a more efficient *real* resize of the object, and will force freeglut to rebuild some infrastructure, but would work. There is no "create" event for these; treat creation as synchronous. * Define a new API function that is synchronous, and provides some indication of success/failure. What would you do for resizing a RenderingArea? You seem to have the same three options. > Pbuffers are things I need *NOW* not at some time in the indefinite futur= e.=20 > Operations > on them utterly MUST happen immediately or they are practically useless. = =20 I understand. [...] > >Or would glutSetDrawingArea() invalidate the current window setting? >=20 > Yes. You can't meaningfully have two rendering areas open at the same Okay. I don't care for that, but alright. (The alternative was not to have two rendering areas active, but rather to have a rendering area selected---possibly a window---and to have a "current window" that could be used for adding menus, etc. I don't care for that, either. To me, both are a bit ugly.) > >It was marked as experimental in the commit. I have nothing against > >replacing it with something better, but since discourse on the API > >seemed to be winding down, and Nigel's suggested API looked like a pretty > >good first approximation, and since things tend to languish without > >implementation sometimes, I went ahead and did it. >=20 > I understand - and it has been useful in firming up the concepts. Agreed. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Nigel S. <ni...@ni...> - 2004-02-21 03:14:27
|
> That completely sucks. You are saying that if I want a differently > sized off-screen area and ask freeglut to do it - then the rendering > area won't change size immediately? > That's unusable. Agreed, it should be synchronous for offscreen windows and there should be a means to query the -actual- size: glutGet(GLUT_WINDOW_WIDTH); > That right there is the death-knell of treating pbuffers as Windows. Not so fast... :-) > Pbuffers are things I need *NOW* not at some time in the indefinite > future. Operations > on them utterly MUST happen immediately or they are practically > useless. Since X doesn't > allow windows to be created instantly, they cannot have that immediacy - > hence pbuffers are mot definitely not windows and windows are most > definitely not pbuffers. I don't see that pbuffers should be constrained to having the (well understood) limitations of system level windows. It seems that we'd be going out of our way to make things unworkable to do this. Yes, we have to admit that a system window and offscreen windows have some different characteristics, but I don't see that the GLUT abstraction doesn't allow for that. > I understand - and it has been useful in firming up the concepts. Yep. You seem to have the impression that it should be compulsory to register callbacks for an offscreen window. My general concept was that an offscreen window could be used either via callbacks, or directly using: glutInitDisplayMode(... | GLUT_OFFSCREEN); int id = glutCreateWindow(); ... glutSetWindow(id); draw(); ... glutReshapeWindow(width,height); draw(); ... glutDestroyWindow(id); > Having two or more GLUT windows open at the same time is just asking > for trouble because you have NO control over the rendering timing. If there is no display callback registered for the offscreen window then updates are completely controlled by the application code. > As I have said (FREQUENTLY) pbuffers are NOT LIKE WINDOWS - you don't > use them like that. It has also been said that it could be useful to treat a pbuffer as a window. Those who don't want to register callbacks simply don't need to register callbacks. Those who want to have offscreen windows (for whatever reason) have an option. The other advantages are consistency in the GLUT API, and retaining the relationship between windows and OpenGL contexts. > I think that if we make as few assumptions about what a 'buffer' is as > possible (beyond that OpenGL will render into it) - then our code should > be extensible as we learn more. I find that line of reasoning a distraction. Offscreen rendering has been around for years, it fits reasonably well with the existing API (not withstanding some fine print in the documentation) and offers a fair degree of flexibility. From an OpenGL point of view, a GLUT window is primarily something that is drawn into. The surrounding functionality is optional. If we could rename glutWindow to glutGlContext then we could have mutually exclusive GLUT_WINDOW and GLUT_OFFSCREEN modes. Instead, we'll overload the concept of a glutWindow rather than an OpenGL context. Nigel |
From: Richard R. <sf...@ol...> - 2004-02-19 14:21:06
|
On Thu, Feb 19, 2004 at 12:27:18AM -0600, Steve Baker wrote: > Richard Rauch wrote: >=20 > >It's a problem for offscreen windows, since you probably do not want > >an initial, automatic redisplay. But you have to register a display > >callback. >=20 > This comes back to my gut feeling that the whole concept of offscreen > rendering areas being windows at all is fundamentally wrong. Putting that aside for now: I believe that it is *wrong* to force a glutPostRedisplay() from within the function that registers the callback. That line of code is why I started this thread. If the caller wants to do that, that's fine. They know where to find glutPostRedisplay(). Forcing it just doesn't make any sense, and is possibly at root for some problems we've had with the timing of regular window redisplays. Since you, in this long message about the evils of offscreen windows, haven't actually addressed the point of the bug, I will assume that you agree that the forced redisplay is a bug. (No other event registration *causes* an immediate event of the type that it is registering.) But, off on the tangent: > I can't imagine practical applications of offscreen rendering wanting > any kind of callbacks at all. I can. However, "I can't imagine" is not a reason to waste our time and energy making it harder for someone later to do things that we didn't think of. So even if wracking our brains failed to yield any examples as reasonable, I don't see the need to spend inordinate effort and time introducing a class hierarchy and new terminology, rolling out new functions and deprecating old, just to split the hair of a window vs. a rectangular drawing area. Not at this late date. (And this is really much more important than whether we can come up with examples, or can agree on them being practical applications.) As for offscreen "windows": The current form works, is very little effort, can be readily extended if the need ever arises, and gracefully fails the non-trivial stuff. (You have, in writing this, probably exerted rather more effort than was required to implement the current offscreen support. I know that I've exerted much more in replying.) > The most likely need is to be inside an ON-screen window redraw event > callback - and to want to switch over to drawing into the off-screen > window - then to use the contents in continuing to render the on-screen > area. I don't know what you mean by "the most likely need". Surely you can't mean that you want to identify a single use for this feature and then take great pains to block alternate uses? That can't be right, but it's what I'm getting when I read the above in the context of your message. > I still maintain that the best way to do this stuff is to have a hierarchy > of class types (yes, I know this isn't a C++ program - but that doesn't s= top > you from thinking in an OOP way): >=20 > Base class: A rendering area. >=20 > Derived class #1: A window. >=20 > Derived class #2: An off-screen rendering area. If we were building a new library from the ground up, I could perhaps get behind this view. We're not. It seems to me that the only "benefit" of this is that it would take us further away from a positive (if hard to justify) feature that we are only a breath away from, right now. [...] > This elegantly removes any issues of window-like behaviour having to > be disabled or artificially emulated for things like off-screen rendering > areas that really are nothing like a window. That's a matter of opinion. (^& To me, a window is *primarily* a rectangular drawing area. I believe that I've said this before so I won't reiterate why. And, to me, the elegance of Nigel's suggested API is that it does extend the notion of windows in a natural manner, within the scope of what GLUT has traditionally offered. No massive redesign, no breaking old programs, etc. Adding offscreen support for any code is about as simple as flipping on a bit prior to opening a window. > This distinction is going to get ever more critical as OpenGL grows to > allow rendering into vertex arrays and such like. Rendering into vertex arrays? I'm not sure that I understand this correctly. OpenGL will support writing 3D shaded imagery into the arrays of vertex data that define coordinates? That doesn't parse well into my vocabulary. (^& Can you explain, or give a URL reference? > All this effort to make off-screen areas behave like windows just > screams: "I'm a horrible kludge". I'm sorry. Effort? The vast bulk of the effort has gone into reading, and replying to, your comments about the change. Doing the actual work was very quick and easy. Probably about 50 or 60 lines, total, were written or changed. Also, this "horrible kludge" has helped me track down what is very possibly the bug that caused the SGI/Sun guy to have extra/early window redisplays (if memory serves). So, the point of this thread (inasmuch as it has to do with the subject) is that the offscreen windows helped locate what appears to be a well-hidden bug. While that does not in and of itself earn the feature a permament residency status, it *hardly* labels it a "horrible kludge". Rather, it helped find a horrible kludge. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Steve B. <sjb...@ai...> - 2004-02-19 15:01:50
|
Richard Rauch wrote: > On Thu, Feb 19, 2004 at 12:27:18AM -0600, Steve Baker wrote: > Putting that aside for now: I believe that it is *wrong* to force > a glutPostRedisplay() from within the function that registers the > callback. That line of code is why I started this thread. When you say "within the function that registers the callback" - do you mean: a) The application's function that calls glutDisplayFunc? If so, I would say it's unnecessary - but not wrong. GLUT doesn't prohibit it - and it's the kind of thing an application writer might do "just in case" because he's unsure of GLUT's behavior. b) Within glutDisplayFunc itself? If so, then it absolutely is necessary because you've said that off-screen rendering areas are treated just like regular windows - so they have to have the same behaviour or all the messy little exceptions like this one will confuse the application writers no end. If you are going to pretend that these rendering areas are actually windows then they'd better behave EXACTLY like them. My entire point, however, is that these AREN'T regular windows and attempting to treat them as if they were is going to create a bunch of these kinds of uglinesses. >>I can't imagine practical applications of offscreen rendering wanting >>any kind of callbacks at all. > > > I can. Please explain. > However, "I can't imagine" is not a reason to waste our time and > energy making it harder for someone later to do things that we > didn't think of. Well - perhaps I should use stonger language for your benefit. "There are NO practical applications whatever of offscreen rendering that demand callbacks." Does that clarify matters? There is EVERY good reason to spend time and energy keeping the API clean and readily comprehensible. Giving people the idea that these things are really windows is making life more confusing for them. The API could really be much simpler to understand if all there was were three functions - something like: handle = glutCreateRenderingArea ( ...whatever... ); glutDestroyRenderingArea ( handle ) ; glutMakeCurrentRenderingArea ( handle ) ; This is very simple to explain, understand, document, etc. It is well worth spending more effort to streamline an API and I'm convinced that it will save us debugging time and explaining time down-the-road as people find more weird problems with things that work with true windows and don't work with off-screen rendering areas. > (You have, in writing this, probably exerted rather more effort > than was required to implement the current offscreen support. I > know that I've exerted much more in replying.) That's neither here nor there. It's worth the effort to keep the API clean. >>This elegantly removes any issues of window-like behaviour having to >>be disabled or artificially emulated for things like off-screen rendering >>areas that really are nothing like a window. > > That's a matter of opinion. (^& > > To me, a window is *primarily* a rectangular drawing area. I > believe that I've said this before so I won't reiterate why. A window is a rectangular drawing area PLUS a bunch of other functionality - titles, keyboard/mouse input, borders, exit and resize widgets, etc. An off-screen rendering area is JUST a rectangular drawing area. Hence, it only makes sense for a Window to be a-kind-of rectangular drawing area. It makes no sense for an off screen buffer to be a-kind-of window. Structuring the API and (probably) the code internals to reflect this natural hierarchy will make life clearer for the end user and remove the nastiness that will inevitably come about when you run into issues like the relevence of glutPostRedisplay. >>This distinction is going to get ever more critical as OpenGL grows to >>allow rendering into vertex arrays and such like. > > Rendering into vertex arrays? I'm not sure that I understand this > correctly. Oh well, never mind. Call us back when you have a clue what you are talking about. The idea is a simple one - in OpenGL 2.0 there will be 'buffers' - that are generally presumed to reside on the graphics card. Frame buffer areas (ie pbuffers), texture maps, vertex arrays - and possibly some new kinds of things like lookup tables that you can read from a vertex shader. These are all just 'buffers'. So you can render into a texture map, render into an off-screen buffer or render into a vertex array. You can also texture using a vertex array, use a frame buffer as vertex shader's lookup table...whatever - because they are now all just buffers. In this specific case, rendering into a vertex array would solve one huge restriction of present Vertex shaders. Right now, they are STRICTLY one vertex in equals one vertex out. So you can't use shaders to do things like generating fractal geometry for nice crinkly looking mountain ranges because you still have to stuff all the vertices into the graphic pipe somehow. This new feature would allow you to do something like rendering a height field stored in a texture map into a vertex buffer so that the output of your first rendering phase would be the vertex coordinates of the second rendering phase. Given that the first rendering phase will typically use a fragment shader to write out the vertex array - and modern graphics cards allow full floating point 'pixels' in their off-screen rendering areas - you can see that using the 'rendering' paradigm to generate 'vertices' instead of 'pixels' makes best use of the graphics hardware. So - now back to freeglut. In my scheme - we would have a basic concept of a rendering region - with properties that are little more than height, width, number of components (1, 2, 3 or 4) and precision (char, uchar, short, ushort, int, uint, float). A window would be a rendering region with the possibilities of having borders, a title and user interaction (and therefore callbacks). An OpenGL 'buffer' would be a rendering region that can be attached to a vertex array or turned magically into a texture...both things that a 'window' can't do. > I'm sorry. Effort? The vast bulk of the effort has gone into reading, > and replying to, your comments about the change. Doing the actual work > was very quick and easy. Probably about 50 or 60 lines, total, were > written or changed. Cool - so it won't be much grief to toss it and do it right. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
From: Nigel S. <ni...@ni...> - 2004-02-20 02:42:42
|
> b) Within glutDisplayFunc itself? > > If so, then it absolutely is necessary because you've said that > off-screen rendering areas are treated just like regular windows > so they have to have > the same behaviour or all the messy little exceptions like this one will > confuse the application writers no end. If you are going to pretend > that these rendering areas are actually windows then they'd better > behave EXACTLY like them. So, a GLUT program running on a machine without a keyboard, mouse, button box, spaceball should need to be reprogrammed in order for it work in a "reasonable" way? This sounds like a more brittle definition of a window than the reality - optional zbuffer, optional stencil buffer, optional double buffering - applications are expected to manage those alternatives. Yes, the "messy" little exceptions need to be carefully considered. But those come with the territory. If there are no callbacks registered for an offscreen window then no events will happen anyway - the application is in control - no problem here. One of the most appealing features of GLUT/FreeGLUT is that these messy little exceptions have been addressed by reasonably expert people and in the most part, resolved sensibly. > "There are NO practical applications whatever of offscreen > rendering that demand callbacks." Regression testing of standard glutWindow based programs. Webification of glutWindow based programs (server-side rendering). >> To me, a window is *primarily* a rectangular drawing area. I >> believe that I've said this before so I won't reiterate why. > > A window is a rectangular drawing area PLUS a bunch of other > functionality - titles, keyboard/mouse input, borders, exit > and resize widgets, etc. > > An off-screen rendering area is JUST a rectangular drawing area. In the GLUT context, windows and offscreen buffers both have the characteristic of providing a unique OpenGL context. My view of a glut window is an OpenGL context which may have optional extra stuff - onscreen visibility, GUI callback functionality, user input, etc. Nigel |