From: mirv <mi...@us...> - 2008-04-27 17:31:50
|
I've not dealt with single buffered opengl surfaces, but I imagine that due to it being tied to the graphical subsystems fairly tightly (hence the explanation for differences between windows & linux) what about just an update (repaint?) call to the fox widget? glFlush & glFinish will only finish sending opengl commands, but won't actually tell the window manager that the screen needs updating, something I suspect will cause problems due to the single buffer being used. Of course, I could be completely wrong, but hey, worth a try! mirv the Silly Fish. On Sun, Apr 27, 2008 at 7:07 PM, The Devils Jester < the...@gm...> wrote: > Because I dont draw the entire scene just the small portion that has > changed, and to do this I rely on the buffer copying when I flip, not > switching, and there are apparently some drivers (In Vista mostly) > that do not support the copying method. > > The only solution that I have found is to use a Single buffer, which > works for my purposes perfectly except for this issue. > > Why would you need to call glFlush() before glFinish(), when they do > the same thing, except glFinish() wont return until everything is > passed? > > These commands only help to force the OpenGL commands 'right now', > however that is not the issue, as I can wait for a half hour and the > FXGLCanvas still doesnt update. Still I remember trying both together > anyway, just to see, and it didnt help at all. > > It works fine in Windows, so I am assuming its related to how OpenGL > in Linux runs faster, but jerky, and Slower but Smooth in Windows. > > It usually only happens when I have a small section to draw. The > bigger section, the less likely it is to happen. Its like OpenGL is > still waiting on more, even after glFlush() and glFinish(). > > On Sun, Apr 27, 2008 at 12:30 PM, Mr. Grue <mr...@cl...> wrote: > > > > glFlush() followed by a glFinish() should block until everything is > > updated. > > > > but then, this is why i pretty much always use double buffering. i > > don't trust drawing into the front buffer. > > > > remind me again why you're not double buffering? > > > > - grue > > > > > > > > On Sat, Apr 26, 2008 at 12:14 PM, The Devils Jester > > <the...@gm...> wrote: > > > > > > > > > > > > In Linux, OpenGL doesnt update as often. I dont know what this is a > > > result of, but it results in a few problems: > > > > > > Rendering is faster in Linux then Windows. This from what I gather is > > > because Windows updates the display more often (Everything is > > > smoother, but slower in Windows). > > > > > > Using a single buffer, Linux isnt updating when I need it to, so the > > > onscreen display is not always what it should be when I draw small > > > portions (and not the whole thing again). > > > > > > Still using a single buffer, and drawing small, changed portions, is > > > there a way I can force OpenGL in Linux to update the FXGLCanvas more > > > often? (I already have glFlush() and glFinish() commands where > > > needed). > > > > > > -- > > > If you make something that any idiot can use, only idiots will use it. > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > > Don't miss this year's exciting event. There's still time to save > $100. > > > Use priority code J8TL2D2. > > > > > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > > _______________________________________________ > > > Foxgui-users mailing list > > > Fox...@li... > > > https://lists.sourceforge.net/lists/listinfo/foxgui-users > > > > > > > > > > > -- > If you make something that any idiot can use, only idiots will use it. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Foxgui-users mailing list > Fox...@li... > https://lists.sourceforge.net/lists/listinfo/foxgui-users > |