From: Rick H. <fox...@ya...> - 2010-04-06 21:20:36
|
How would you describe a thread-safe glut loop? What would be its features? On Tue Apr 6th, 2010 4:59 PM EDT Alex G. wrote: >How about a thread-safe freeglut? I 'm the type of person of >questionable sanity that would have several independent glut loops >running at once if possible. > >Alex G. > > >On 04/06/2010 06:45 PM, Fay, John F Dr CTR USAF AFMC 46 SK wrote: >> Gentlemen, >> >> I can't find it in my e-mail archives, but I remember suggesting >> that sometime around the vernal equinox I start making noises about >> freeglut 2.8.0. The vernal equinox (in the northern hemisphere, at >> least) has come and gone, and so I am now starting to make noises. >> >> Dr. John F. Fay >> Technical Fellow >> Jacobs Technology TEAS Group >> 850-883-1294 >> >> >> -----Original Message----- >> From: John F. Fay [mailto:joh...@cy...] >> Sent: Friday, November 27, 2009 10:48 PM >> To: FreeGLUT developers list >> Subject: [Freeglut-developer] What's next? >> >> Gentlemen, >> >> With the release of 2.6.0, it is now time for the better once >> again >> to become the enemy of the good. There were, I think, quite a few >> things that would be good to put into "freeglut" but which were not >> important enough to hold up the release. >> >> The first item on my list is getting our OSX ducks in a row. I >> am >> told that the build problems that ensued from the OSX/Linux patch can >> be fixed by bringing the build/configure tools up to date. Does >> anybody here have any thoughts on the subject? >> >> - John >> >> >> ------------------------------------------------------------------------ >> ------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and >> focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> > > >------------------------------------------------------------------------------ >Download Intel® Parallel Studio Eval >Try the new software tools for yourself. Speed compiling, find bugs >proactively, and fine-tune applications for parallel performance. >See why Intel Parallel Studio got high marks during beta. >http://p.sf.net/sfu/intel-sw-dev >_______________________________________________ >Freeglut-developer mailing list >Fre...@li... >https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Rick H. <fox...@ya...> - 2010-04-06 21:59:22
|
This can be done today across processes and shared memory in Linux, and named pipes in Windows. Do we want / need multiple windows controlled by a single process running multiple threads? What s the advantage? I m asking. On Tue Apr 6th, 2010 5:35 PM EDT Paul Martz wrote: >Rick Hodgin wrote: >> How would you describe a thread-safe glut loop? What would be its features? > >App would have multiple threads running concurrently. Each would open their own >GLUT Window, and GLUT would create a corresponding context and make it current, >so multiple contexts current at the same time, to different windows of course as >per GLX spec. Each thread would execute its own glutMainLoop, again concurrent >with other threads doing the same thing. The end effect would be multiple >windows open at once, all updating simultaneously. > >-- > -Paul Martz Skew Matrix Software > http://www.skew-matrix.com/ > >------------------------------------------------------------------------------ >Download Intel® Parallel Studio Eval >Try the new software tools for yourself. Speed compiling, find bugs >proactively, and fine-tune applications for parallel performance. >See why Intel Parallel Studio got high marks during beta. >http://p.sf.net/sfu/intel-sw-dev >_______________________________________________ >Freeglut-developer mailing list >Fre...@li... >https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Alex G. <mr....@gm...> - 2010-04-06 22:16:06
|
I came across several problems where this would have been an elegant solution. For example, a in a molecular dynamic simulation I would draw some graphs representing some mambo-jumbo. It would also be desirable at times to open another window and view a snapshot of how the particles are distributed. It didn't make sense to have to have everything in one window. In another case, I wanted to have a GUI window operated by the main thread of a program (another simulation), and and have another window controlled by a secondary thread that would render the results of some heavy duty calculations as the results became available. For performance reasons I needed to have each window controlled by a different thread. I ended up scraping the GUI. So yes, it is desirable to have multiple windows controlled by a single process running multiple threads, even if the cases where this would be done are limited. Alex G. On 04/07/2010 12:59 AM, Rick Hodgin wrote: > This can be done today across processes and shared memory in Linux, and named pipes in Windows. > > Do we want / need multiple windows controlled by a single process running multiple threads? What s the advantage? I m asking. > > On Tue Apr 6th, 2010 5:35 PM EDT Paul Martz wrote: > > >> Rick Hodgin wrote: >> >>> How would you describe a thread-safe glut loop? What would be its features? >>> >> App would have multiple threads running concurrently. Each would open their own >> GLUT Window, and GLUT would create a corresponding context and make it current, >> so multiple contexts current at the same time, to different windows of course as >> per GLX spec. Each thread would execute its own glutMainLoop, again concurrent >> with other threads doing the same thing. The end effect would be multiple >> windows open at once, all updating simultaneously. >> >> -- >> -Paul Martz Skew Matrix Software >> http://www.skew-matrix.com/ >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: John T. <nu...@me...> - 2010-04-07 10:08:44
|
On Wed, Apr 07, 2010 at 01:19:18AM +0300, Alex G. wrote: > For example, a in a molecular dynamic simulation I would draw some > graphs representing some mambo-jumbo. It would also be desirable at > times to open another window and view a snapshot of how the particles > are distributed. It didn't make sense to have to have everything in one > window. Nothing stops you from opening multiple windows from a single GLUT "main loop" afaik. They don't have to run on different threads. > In another case, I wanted to have a GUI window operated by the main > thread of a program (another simulation), and and have another window > controlled by a secondary thread that would render the results of some > heavy duty calculations as the results became available. For performance > reasons I needed to have each window controlled by a different thread. I > ended up scraping the GUI. The standard way of doing that sort of thing is have a single "graphics" thread that controls the one or many windows, and offload the heavy calculations on different threads which signal the main thread to redisplay. Again there's no need to have multiple threads control GLUT/GL contexts. Also if you could use multiple processes as someone else suggested. > So yes, it is desirable to have multiple windows controlled by a single > process running multiple threads, even if the cases where this would be > done are limited. I'm not saying it wouldn't be nice to have that option. But I don't see the "need" for it, nor do I find it interesting enough. There are much more common and important cases where you can't use GLUT at the moment and you have to resort to write your own GLX code than multithreaded GLUT context support in my opinion. For instance a long-standing grudge of mine is that I can't integrate the glut main loop processing into my own select() loop as I can't get the underlying X socket without resorting to terrible hacks. -- John Tsiombikas http://nuclear.sdf-eu.org/ |
From: Alex G. <mr....@gm...> - 2010-04-07 11:24:50
|
>> In another case, I wanted to have a GUI window operated by the main >> thread of a program (another simulation), and and have another window >> controlled by a secondary thread that would render the results of some >> heavy duty calculations as the results became available. For performance >> reasons I needed to have each window controlled by a different thread. I >> ended up scraping the GUI. >> > The standard way of doing that sort of thing is have a single "graphics" > thread that controls the one or many windows, and offload the heavy > calculations on different threads which signal the main thread to > redisplay. Again there's no need to have multiple threads control > GLUT/GL contexts. > Thats what I'm currently doing, and I can do that when I have one window, or a fixed number of windows. Needing to create and destroy windows complicates matters a lot. > Also if you could use multiple processes as someone else suggested. > I definitely could if portability was not a major concern. That would be more suited when graphics is the main concern of the application, which in my case, isn't. >> So yes, it is desirable to have multiple windows controlled by a single >> process running multiple threads, even if the cases where this would be >> done are limited. >> > I'm not saying it wouldn't be nice to have that option. But I don't see > the "need" for it, nor do I find it interesting enough. There are much > more common and important cases where you can't use GLUT at the moment > and you have to resort to write your own GLX code than multithreaded > GLUT context support in my opinion. > > I'm not trying to say that multithreaded GLUT is or should be the number one priority, but considering the multiple cores modern processors offer, I see it as the logical evolution of freeglut, whether it happens today, in the next release, or in a few releases. > For instance a long-standing grudge of mine is that I can't integrate > the glut main loop processing into my own select() loop as I can't get > the underlying X socket without resorting to terrible hacks. > > One grudge I have is not being able to order a glut redisplay from a different thread without some sort of hack. Here are a few other things I think could be improved: * glutFullScreenToggle() doesn't leave fullscreen mode on Windows. * I can't fullscreen on a secondary monitor * Trying to create windows from separate treads will segfault rather than freeglut elegantly returning an error. How interesting or useful those features would be is not for me alone to judge, but I put them forth as proposals for freeglut 2.8.0. Alex G. |
From: Fay, J. F Dr C. U. A. 46 S. <joh...@eg...> - 2010-04-07 16:10:50
|
Addressing the third item first, "freeglut" should NEVER segfault. If you have some simple sample code I would like to take a look at the problem. The other two things are also definitely worth looking into. Dr. John F. Fay Technical Fellow Jacobs Technology TEAS Group 850-883-1294 -----Original Message----- From: Alex G. [mailto:mr....@gm...] Sent: Wednesday, April 07, 2010 6:28 AM To: fre...@li... Subject: Re: [Freeglut-developer] What s next? One grudge I have is not being able to order a glut redisplay from a different thread without some sort of hack. Here are a few other things I think could be improved: * glutFullScreenToggle() doesn't leave fullscreen mode on Windows. * I can't fullscreen on a secondary monitor * Trying to create windows from separate treads will segfault rather than freeglut elegantly returning an error. How interesting or useful those features would be is not for me alone to judge, but I put them forth as proposals for freeglut 2.8.0. Alex G. |
From: Fay, J. F Dr C. U. A. 46 S. <joh...@eg...> - 2010-04-07 16:10:46
|
Can we support the retrieval of the underlying socket in a platform-independent way? Dr. John F. Fay Technical Fellow Jacobs Technology TEAS Group 850-883-1294 -----Original Message----- From: John Tsiombikas [mailto:nu...@me...] Sent: Wednesday, April 07, 2010 5:09 AM To: fre...@li... Subject: Re: [Freeglut-developer] What s next? <snip> For instance a long-standing grudge of mine is that I can't integrate the glut main loop processing into my own select() loop as I can't get the underlying X socket without resorting to terrible hacks. -- John Tsiombikas http://nuclear.sdf-eu.org/ |
From: John T. <nu...@me...> - 2010-04-08 23:47:48
|
On Wed, Apr 07, 2010 at 10:46:33AM -0500, Fay, John F Dr CTR USAF AFMC 46 SK wrote: > Can we support the retrieval of the underlying socket in a > platform-independent way? Since other window systems out there don't communicate with the window system through sockets probably not. However every window system has some potentially useful data, and we could export them in a uniform way accross window systems. The thing is, portability is great and I'm all for it, but when you only work on a particular platform and you have other non-portable stuff going on anyway, it's a shame to not being able to rely on GLUT for a simple way to set up OpenGL rendering and event handling. I suggest a simple interface such as glutGetPlatformData that may be used to retrieve platform-specific data from glut internals. As long as it's being made absolutely clear that relying on that will make your program non-portable (unless of course you handle any platform differences with ifdefs and such), I don't see the harm in making it possible to access those things. >From the top of my head, here's a short list of potentially useful internal data that could be exported through such an interface: - Pointer to Display structure (X11) - Current window identifier (X11: XID, W32: HWND) - OpenGL context (X11: GLXContext, W32: HRC) The socket I've been barking about can be retrieved from the X11 Display structure, and it's necessary for further X calls to the same display anyway. The rest pretty much correspond one to one so they could be retreivable with the same call. Window identifiers are definitely quite useful as they would make it possible to easily embed GLUT windows into larger GUI applications. Another maybe complimentary idea is to allow somehow the user to register arbitrary events that GLUT main loop will handle and call user callbacks when they go off. But again we stumble on platform differences. On windows the user would have to pass HANDLEs corresponding to files, sockets, signals, etc, while on UNIX that would have to be file descriptors. Still a neat idea I think. -- John Tsiombikas http://nuclear.sdf-eu.org/ |
From: Chris M. <ch...@al...> - 2010-04-09 01:43:38
|
On 4/8/2010 7:47 PM, John Tsiombikas wrote: > >> From the top of my head, here's a short list of potentially useful > internal data that could be exported through such an interface: > > - Pointer to Display structure (X11) > - Current window identifier (X11: XID, W32: HWND) > - OpenGL context (X11: GLXContext, W32: HRC) > > The socket I've been barking about can be retrieved from the X11 Display > structure, and it's necessary for further X calls to the same display > anyway. The rest pretty much correspond one to one so they could be > retrievable with the same call. Window identifiers are definitely quite > useful as they would make it possible to easily embed GLUT windows into > larger GUI applications. Yes! The ability to embed GLUT windows would be very useful. As would the ability to hand off the opengl context to another routine for drawing... --Chris |
From: Clive M. <cli...@ms...> - 2010-04-09 16:19:06
|
I think it's already been said that there should be no compromise on the portability of freeglut. I think GLUT & freeglut provide a powerful means for people to get started with OpenGL. It's a great tutorial mechanism and it's clear to me that the guides to OpenGL could hardly work without GLUT. The portability allows tutorial work to take place on almost any platform and furthermore, what is learned is itself portable. For non-tutorial applications it strikes me that the developer would likely be best off simply taking the source code from freeglut and bending it in whatever fashion they need if the basic freeglut library doesn't provide enough control. Such a fork is not likely to miss out on stunning new features that would emerge in subsequent versions of freeglut. I doubt that anyone of us is about to add touch-interface gesture code to freeglut? To aid this kind of one-time portability/fork it would probably be helpful if the 'build from source' process was extremely simple and clean. The code by my reckoning is around 25k lines so it's not so big that absorbing the code into a main project is prohibitive. However, I don't object at all to a mechanism that would reveal non-portable aspects of freeglut. Clive. freeglut_callbacks.c 367 lines freeglut_cursor.c 280 lines freeglut_display.c 98 lines freeglut_ext.c 226 lines freeglut_font.c 376 lines freeglut_gamemode.c 594 lines freeglut_geometry.c 1215 lines freeglut_glutfont_definitions.c 108 lines freeglut_init.c 1166 lines freeglut_input_devices.c 395 lines freeglut_menu.c 1002 lines freeglut_misc.c 214 lines freeglut_overlay.c 45 lines freeglut_spaceball.c 454 lines freeglut_structure.c 596 lines freeglut_teapot.c 200 lines freeglut_videoresize.c 50 lines freeglut_state.c 895 lines largest function 414 lines freeglut_window.c 1743 lines largest function 367 lines freeglut_joystick.c 1801 lines largest function 430 lines freeglut_main.c 2296 lines largest function 725 lines freeglut_font_data.c 2020 lines freeglut_stroke_mono_roman.c 2849 lines freeglut_stroke_roman.c 2849 lines freeglut_internal.h 960 lines freeglut_teapot_data.h 2429 lines largest function 1025 lines Total 25228 lines Total number of files: 26 _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 |
From: Diederick C. N. <dc...@gm...> - 2010-04-10 01:57:01
|
Hi All, On Sat, Apr 10, 2010 at 12:18 AM, Clive McCarthy <cli...@ms...> wrote: > > I think it's already been said that there should be no compromise on the portability of freeglut. I think GLUT & freeglut provide a powerful means for people to get started with OpenGL. It's a great tutorial mechanism and it's clear to me that the guides to OpenGL could hardly work without GLUT. The portability allows tutorial work to take place on almost any platform and furthermore, what is learned is itself portable. > > For non-tutorial applications it strikes me that the developer would likely be best off simply taking the source code from freeglut and bending it in whatever fashion they need if the basic freeglut library doesn't provide enough control. Such a fork is not likely to miss out on stunning new features that would emerge in subsequent versions of freeglut. I doubt that anyone of us is about to add touch-interface gesture code to freeglut? I agree with the previous posts (John T) that a general interface that provides access to platform dependent information as he outlined would be a good tool for power users. It indeed only has to be clearly marked to lead to non-platform independent code. They should not have to resort to hacking the sourcecode themselves for such relatively basic (and probably common_ needs. Furthermore, we previously discussed to make an effort to clear up the #ifdef situation to have cleaner and simpler code to work with. Such an internal revision step might be a good place to start before adding new functionality. I myself will try, but the earliest I will find time for this is in June. Then, we discussed getting a native OSX port done. I think it is good to first clean up the #ifdef situation before further inviting people to work on this. As another side note: Is there any way to have the bug and feature request trackers send a message to this list when a new post is added? This way we'll all see them and can deal with them efficiently. Best, Dee |
From: Alex G <mr....@gm...> - 2010-04-10 21:49:36
|
On 04/10/2010 04:56 AM, Diederick C. Niehorster wrote: > Hi All, > > On Sat, Apr 10, 2010 at 12:18 AM, Clive McCarthy<cli...@ms...> wrote: > >> I think it's already been said that there should be no compromise on the portability of freeglut. I think GLUT& freeglut provide a powerful means for people to get started with OpenGL. It's a great tutorial mechanism and it's clear to me that the guides to OpenGL could hardly work without GLUT. The portability allows tutorial work to take place on almost any platform and furthermore, what is learned is itself portable. >> >> For non-tutorial applications it strikes me that the developer would likely be best off simply taking the source code from freeglut and bending it in whatever fashion they need if the basic freeglut library doesn't provide enough control. Such a fork is not likely to miss out on stunning new features that would emerge in subsequent versions of freeglut. I doubt that anyone of us is about to add touch-interface gesture code to freeglut? >> > I agree with the previous posts (John T) that a general interface that > provides access to platform dependent information as he outlined would > be a good tool for power users. It indeed only has to be clearly > marked to lead to non-platform independent code. They should not have > to resort to hacking the sourcecode themselves for such relatively > basic (and probably common_ needs. > > How about a naming scheme of glxut*() and wglut*() for platform-specific code? Alex G. P.S. John, I'm still searching through old revisions for the code that caused freeglut to segfault. I'll post it as soon as I can find it. |
From: John T. <nu...@me...> - 2010-04-11 09:44:59
|
On Sun, Apr 11, 2010 at 12:49:25AM +0300, Alex G wrote: > How about a naming scheme of glxut*() and wglut*() for platform-specific > code? I don't think that's necessary, at least for the interface I proposed a few emails back. As I pointed out most of the state we'd want to expose correspond 1-to-1 between window systems (such as window identifiers, and OpenGL contexts), so I think they should be retrievable with the same call. Something like glutGetPlatformData(GLUT_GLCONTEXT) that would return a void pointer and leave it to the user to use it appropriately. I'm not 100% certain that this is the best way to do it. It's just the best I could think of. Any other ideas? -- John Tsiombikas http://nuclear.sdf-eu.org/ |
From: Rick H. <fox...@ya...> - 2010-04-06 22:28:22
|
These things you talk about can be done today, mostly literally, with parallel threads building the rendering data set(s), and then spinning or activating a sleeping external rendering engine. It doesn t require multiple contexts in a single glut process, something that would slow glut down observedly by requiring greater indirection and/or passed parameters per API call. Glut should be small, tight and fast. Have you worked with cross-process programming? It could easily do what you describe. On Tue Apr 6th, 2010 6:19 PM EDT Alex G. wrote: >I came across several problems where this would have been an elegant >solution. > >For example, a in a molecular dynamic simulation I would draw some >graphs representing some mambo-jumbo. It would also be desirable at >times to open another window and view a snapshot of how the particles >are distributed. It didn't make sense to have to have everything in one >window. > >In another case, I wanted to have a GUI window operated by the main >thread of a program (another simulation), and and have another window >controlled by a secondary thread that would render the results of some >heavy duty calculations as the results became available. For performance >reasons I needed to have each window controlled by a different thread. I >ended up scraping the GUI. > >So yes, it is desirable to have multiple windows controlled by a single >process running multiple threads, even if the cases where this would be >done are limited. > >Alex G. > > >On 04/07/2010 12:59 AM, Rick Hodgin wrote: >> This can be done today across processes and shared memory in Linux, and named pipes in Windows. >> >> Do we want / need multiple windows controlled by a single process running multiple threads? What s the advantage? I m asking. >> >> On Tue Apr 6th, 2010 5:35 PM EDT Paul Martz wrote: >> >> >>> Rick Hodgin wrote: >>> >>>> How would you describe a thread-safe glut loop? What would be its features? >>>> >>> App would have multiple threads running concurrently. Each would open their own >>> GLUT Window, and GLUT would create a corresponding context and make it current, >>> so multiple contexts current at the same time, to different windows of course as >>> per GLX spec. Each thread would execute its own glutMainLoop, again concurrent >>> with other threads doing the same thing. The end effect would be multiple >>> windows open at once, all updating simultaneously. >>> >>> -- >>> -Paul Martz Skew Matrix Software >>> http://www.skew-matrix.com/ >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Freeglut-developer mailing list >>> Fre...@li... >>> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> > > >------------------------------------------------------------------------------ >Download Intel® Parallel Studio Eval >Try the new software tools for yourself. Speed compiling, find bugs >proactively, and fine-tune applications for parallel performance. >See why Intel Parallel Studio got high marks during beta. >http://p.sf.net/sfu/intel-sw-dev >_______________________________________________ >Freeglut-developer mailing list >Fre...@li... >https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Paul M. <pm...@sk...> - 2010-04-06 21:51:38
|
Rick Hodgin wrote: > How would you describe a thread-safe glut loop? What would be its features? App would have multiple threads running concurrently. Each would open their own GLUT Window, and GLUT would create a corresponding context and make it current, so multiple contexts current at the same time, to different windows of course as per GLX spec. Each thread would execute its own glutMainLoop, again concurrent with other threads doing the same thing. The end effect would be multiple windows open at once, all updating simultaneously. -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ |
From: Alex G. <mr....@gm...> - 2010-04-06 21:54:26
|
Exactly. Alex G. On 04/07/2010 12:35 AM, Paul Martz wrote: > Rick Hodgin wrote: > >> How would you describe a thread-safe glut loop? What would be its features? >> > App would have multiple threads running concurrently. Each would open their own > GLUT Window, and GLUT would create a corresponding context and make it current, > so multiple contexts current at the same time, to different windows of course as > per GLX spec. Each thread would execute its own glutMainLoop, again concurrent > with other threads doing the same thing. The end effect would be multiple > windows open at once, all updating simultaneously. > > |
From: Chris M. <ch...@al...> - 2010-04-07 14:13:31
|
On 4/6/2010 5:35 PM, Paul Martz wrote: > Rick Hodgin wrote: >> How would you describe a thread-safe glut loop? What would be its features? > > App would have multiple threads running concurrently. Each would open their own > GLUT Window, and GLUT would create a corresponding context and make it current, > so multiple contexts current at the same time, to different windows of course as > per GLX spec. Each thread would execute its own glutMainLoop, again concurrent > with other threads doing the same thing. The end effect would be multiple > windows open at once, all updating simultaneously. Please don't break cross-platform portability of FreeGLUT in order to add new features. That is one of the *primary* benfits of GLUT/FreeGLUT. N.B. GLX not what is used on either windows or mac os x. Cheers, Chris |
From: Alex G. <mr....@gm...> - 2010-04-06 21:53:08
|
Basically, you would have a thread-local glut context (for the lack of a better name). Let's say I'm in thread A. I call glutInit, set up my window(s), then call glutMainLoop. I have a GL context, and everything necessary to draw. Now, I do the the same thing from thread B. I should get a different context, and everything that I do in thread B should not affect the state of what I have already set up in thread A. In my experience with freeglut 2.6.0, trying to create several windows in different threads ended with segmentation faults. I'm not sure how good my explanation is, but I'm thinking somewhere along the lines of CUDA, if you're familiar with that. The first context is created automatically, but it's also possible to manually create and manipulate contexts. The way I'm envisioning this for freeglut is: if I only need one main loop, than I can continue to use freeglut as usual, and not have to worry about anyhting new, but if I wanted several loops, I could explicitly create and use them. I know a troll could explain this better, so please let me know where I'm utterly unclear. Alex G. On 04/07/2010 12:20 AM, Rick Hodgin wrote: > How would you describe a thread-safe glut loop? What would be its features? > > On Tue Apr 6th, 2010 4:59 PM EDT Alex G. wrote: > > >> How about a thread-safe freeglut? I 'm the type of person of >> questionable sanity that would have several independent glut loops >> running at once if possible. >> >> Alex G. >> >> >> On 04/06/2010 06:45 PM, Fay, John F Dr CTR USAF AFMC 46 SK wrote: >> >>> Gentlemen, >>> >>> I can't find it in my e-mail archives, but I remember suggesting >>> that sometime around the vernal equinox I start making noises about >>> freeglut 2.8.0. The vernal equinox (in the northern hemisphere, at >>> least) has come and gone, and so I am now starting to make noises. >>> >>> Dr. John F. Fay >>> Technical Fellow >>> Jacobs Technology TEAS Group >>> 850-883-1294 >>> >>> >>> -----Original Message----- >>> From: John F. Fay [mailto:joh...@cy...] >>> Sent: Friday, November 27, 2009 10:48 PM >>> To: FreeGLUT developers list >>> Subject: [Freeglut-developer] What's next? >>> >>> Gentlemen, >>> >>> With the release of 2.6.0, it is now time for the better once >>> again >>> to become the enemy of the good. There were, I think, quite a few >>> things that would be good to put into "freeglut" but which were not >>> important enough to hold up the release. >>> >>> The first item on my list is getting our OSX ducks in a row. I >>> am >>> told that the build problems that ensued from the OSX/Linux patch can >>> be fixed by bringing the build/configure tools up to date. Does >>> anybody here have any thoughts on the subject? >>> >>> - John >>> >>> >>> ------------------------------------------------------------------------ >>> ------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Freeglut-developer mailing list >>> Fre...@li... >>> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Freeglut-developer mailing list >>> Fre...@li... >>> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >>> >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |