f



GLUT and double buffering. ...

Is GLUT *really* the only way by which do double-buffering in
OpenGL and, so, if I don't uaw se it. will my animations "flash"?
Is there, for that matter, another way to do double-buffering
that avoids GLUT?


Russell
0
russell
12/12/2015 12:01:41 PM
comp.graphics.api.opengl 7074 articles. 1 followers. Post Follow

8 Replies
664 Views

Similar Articles

[PageSpeed] 29

Russell,

> Is GLUT *really* the only way by which do double-buffering
> in OpenGL

No.

Look at, in a basic non-GLUT OpenGL initialisation, where the
PIXELFORMATDESCRIPTOR structure is initialized.   The "dwFlags" field can,
and mostly does, include PFD_DOUBLEBUFFER.

You migh take a look at the following tutorial, which describes a creating a
working OpenGL environment (I think I took the above info from there)
http://nehe.gamedev.net/tutorial/creating_an_opengl_window_win32/13001/

Regards,
Rudy Wieser


-- Origional message:
<russell.potter3@gmail.com> schreef in berichtnieuws
f02abf09-e6e2-41d4-8ea3-0cc16fb4b647@googlegroups.com...
>
> Is GLUT *really* the only way by which do double-buffering in
> OpenGL and, so, if I don't uaw se it. will my animations "flash"?
> Is there, for that matter, another way to do double-buffering
> that avoids GLUT?
>
>
> Russell


0
R
12/12/2015 1:39:03 PM
>
> Is GLUT *really* the only way by which do double-buffering in
> OpenGL and, so, if I don't uaw se it. will my animations "flash"?
> Is there, for that matter, another way to do double-buffering
> that avoids GLUT?

If we neglect the quite offensive tone of your message, you are probably 
asking wrong question. For example, on windows the most common 
flickering problem beginners are facing is connected to wrong handling 
of window background erasure (WM_ERASEBKGRND message). But in this 
particular case, this is purely speculation, since you didn't even 
bother to state operating system you are working on.

0
Leclerc
12/12/2015 8:29:46 PM
Leclerc,

> since you didn't even bother to state operating system
> you are working on.

Whoops!   Good catch.  A bit presumptious of me to assume Windows and answer
as such ...

Regards,
Rudy Wieser


-- Origional message:
Leclerc <gordan.sikic.remove@this.inet.hr> schreef in berichtnieuws
n4i03q$d63$1@l01news1.ot.hr...
> >
> > Is GLUT *really* the only way by which do double-buffering in
> > OpenGL and, so, if I don't uaw se it. will my animations "flash"?
> > Is there, for that matter, another way to do double-buffering
> > that avoids GLUT?
>
> If we neglect the quite offensive tone of your message, you are probably
> asking wrong question. For example, on windows the most common
> flickering problem beginners are facing is connected to wrong handling
> of window background erasure (WM_ERASEBKGRND message). But in this
> particular case, this is purely speculation, since you didn't even
> bother to state operating system you are working on.
>


0
R
12/12/2015 8:59:41 PM
On Sat, 12 Dec 2015 04:01:41 -0800, russell.potter3 wrote:

> Is GLUT *really* the only way by which do double-buffering in OpenGL

GLUT is never the only way to do anything. It's just a library which
provides a simple, cross-platform interface to the platform's native
functionality.

If you want to know how to do what GLUT does but without GLUT, probably
the easiest solution is to look at the source code for GLUT. Or GLFW, GTK,
Qt, wxWidgets, SDL or SFML (all of which provide similar functionality and
are open source).

0
Nobody
12/14/2015 10:39:03 AM
>> Is GLUT *really* the only way by which do double-buffering in
>> OpenGL and, so, if I don't uaw se it. will my animations "flash"?
>> Is there, for that matter, another way to do double-buffering
>> that avoids GLUT?
> 
> If we neglect the quite offensive tone of your message, you are probably 
> asking wrong question. For example, on windows the most common 
> flickering problem beginners are facing is connected to wrong handling 
> of window background erasure (WM_ERASEBKGRND message). But in this 
> particular case, this is purely speculation, since you didn't even 
> bother to state operating system you are working on.

In what *possible* universe could a question about the flashing of
non- GLUT rendering have an "offensive" tone??? ... (although, I
suppose, one can be offended by the existence of the Tooth Fairy,
if one tries hard enough ... :-)

.... besides, there's a a reason I didn't "bother" to mention in an
OS my question: the group to which I posted this is OpenGL - and
not OS - specific, and I didn't consider the OS to be relevant in my
OpenGL- generic question.  As a matter of fact, I don't even have a
Windows compiler, so an attempt to write a Win32 API-specific program -
although possible - isn't really worth the trouble, not to mention
not necessary ...

Russell
0
russell
12/22/2015 10:17:28 AM
Rudy

> Look at, in a basic non-GLUT OpenGL initialisation, where the
> PIXELFORMATDESCRIPTOR structure is initialized.   The "dwFlags" field can,
> and mostly does, include PFD_DOUBLEBUFFER.
> 
> You migh take a look at the following tutorial, which describes a creating a
> working OpenGL environment (I think I took the above info from there)
> http://nehe.gamedev.net/tutorial/creating_an_opengl_window_win32/13001/

RThanks for that response: trouble is, I don't have a Windows
compiler, so it's going to be difficult to run such a Win32-
heavy solution as that which you describe: I suppose I really
need to re-phrase my question to ask if there's an reasonably
OS-agnostic way to do double-buffering in OpenGL?

(the reason my question concerned GLUT, BTW, is that it's
the only OpenGL context that I'd heard relevant to double-
buffering ...)

Russell
0
russell
12/22/2015 11:13:31 AM
wrote in message 
news:cf38df72-4c21-4d91-887f-d1104f19f0be@googlegroups.com...

> > Look at, in a basic non-GLUT OpenGL initialisation, where the
> > PIXELFORMATDESCRIPTOR structure is initialized.   The "dwFlags" field 
> > can,
> > and mostly does, include PFD_DOUBLEBUFFER.

> > You migh take a look at the following tutorial, which describes a 
> > creating a
> > working OpenGL environment (I think I took the above info from there)
> > http://nehe.gamedev.net/tutorial/creating_an_opengl_window_win32/13001/

> RThanks for that response: trouble is, I don't have a Windows
> compiler, so it's going to be difficult to run such a Win32-
> heavy solution as that which you describe: I suppose I really
> need to re-phrase my question to ask if there's an reasonably
> OS-agnostic way to do double-buffering in OpenGL?

If you scroll down to the bottom of the Lesson01 page as referenced above,
you will find 33 versions in various languages and OSes. Heck, I even had
Fortran 2003 versions for Lessons 1:20 on my web page before Comcast
destroyed my web page.


0
James
12/23/2015 12:49:38 AM
On Tue, 22 Dec 2015 03:13:31 -0800, russell.potter3 wrote:

> I suppose I really need to re-phrase my question to
> ask if there's an reasonably OS-agnostic way to do double-buffering in
> OpenGL?

Double buffering is outside the scope of OpenGL itself. It's down to the
window system, which means that it involves platform-specific functions.

On X11, double-buffering is enabled by specifying the GLX_DOUBLEBUFFER
attribute when using glXChooseVisual() to choose a visual to pass to
glXCreateContext().

On Windows, it's enabled by specifying the PFD_DOUBLEBUFFER flag when
calling ChoosePixelFormat(), setting that format on the DC with
SetPixelFormat(), then creating a GL context for that DC with
wglCreateContext().

The procedure is similar on MacOS X, although there are different
mechanisms for Carbon (C) and Cocoa (Objective-C).

The main reason GLUT was created was to provide a simple, cross-platform
interface to the window system.

You will find similar functionality in any cross-platform GUI toolkit
which includes OpenGL support (e.g. GTK, Qt, wxWidgets), as well as
cross-platform graphics libraries which don't provide more complex GUI
functionality (e.g. GLUT, GLFW, SDL, SFML).

All of those provide cross-platform context management functions by
writing distinct versions of the functions for Windows, X11 and MacOS X.

0
Nobody
12/23/2015 8:44:03 AM
Reply: