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/ |