About the documentation of OpenGL usage in FLTK

[Manolo]

The FLTK doc currently contains this information at https://www.fltk.org/doc-1.4/opengl.html#opengl_subclass :

For double-buffered windows you will need to surround the drawing code with the following code to make sure that both buffers are redrawn:

#ifndef MESA

glDrawBuffer(GL_FRONT_AND_BACK);

#endif // !MESA

... draw stuff here ...

#ifndef MESA

glDrawBuffer(GL_BACK);

#endif // !MESA

None of our test and examples GL-using apps which all use FL_DOUBLE do that.

Is this information (which is there since at least 2008 both in 1.3 and 1.4) obsolete?

[Bill Spitzak]

I believe this is confusing and quite obsolete instructions on how to make an OpenGL window incrementally update (you have to draw the update in both buffers or it will flash as the buffers are swapped). All recommendations now are to completely redraw the OpenGL window from scratch.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/7afdbeb0-2d31-455b-90cc-a98d8e5db4e0n%40googlegroups.com.

[Manolo]

Le mercredi 17 juillet 2024 à 21:22:39 UTC+2, spi...@gmail.com a écrit :

I believe this is confusing and quite obsolete instructions on how to make an OpenGL window incrementally update (you have to draw the update in both buffers or it will flash as the buffers are swapped). All recommendations now are to completely redraw the OpenGL window from scratch.

Thanks Bill. With this explanation, this paragraph makes sense to me.

I would therefore propose to detail a bit more the documentation as follows:

For double-buffered windows (FL_DOUBLE or GLUT_DOUBLE), the recommendation is
to  completely redraw the scene before each buffer swap. Incremental
updating is possible but requires to surround the drawing code as
follows to make sure that both buffers are redrawn:

\code

#ifndef MESA
glDrawBuffer(GL_FRONT_AND_BACK);
#endif // !MESA

... drawing code here ...

#ifndef MESA
glDrawBuffer(GL_BACK);
#endif // !MESA

\endcode

\note
        If you are using the Mesa graphics library, the calls
        to \p glDrawBuffer() are not required and will slow
        down drawing considerably. The preprocessor instructions
        shown above will optimize your code based upon the
        graphics library used.

However, Albrecht and I have noticed that the preprocessor variable MESA

is undefined under Linux where the GL driver is Mesa (version 20 and above).
This would suggest the "\note" above is no longer appropriate.
What would you recommend?

[Bill Spitzak]

Maybe just delete the whole thing. I was only guessing as to it's purpose. I think the MESA test was because MESA does not swap the buffers but instead copies back to front, so this is not needed for MESA.

I think if a programmer sees the window flashing they will figure out how to fix it. And it might not happen on modern systems

--

You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/caa94aa2-3624-42a6-9e1e-b4591021722dn%40googlegroups.com.

[Lauri Kasanen]

On Thu, 18 Jul 2024 14:42:34 -0700
Bill Spitzak <spi...@gmail.com> wrote:

> Maybe just delete the whole thing. I was only guessing as to it's purpose.
> I think the MESA test was because MESA does not swap the buffers but
> instead copies back to front, so this is not needed for MESA.
>
> I think if a programmer sees the window flashing they will figure out how
> to fix it. And it might not happen on modern systems

I think this refers to the ancient history when Mesa was software
rendering only?

- Lauri

[Manolo]

Le jeudi 18 juillet 2024 à 23:42:48 UTC+2, spi...@gmail.com a écrit :

Maybe just delete the whole thing.

Thanks. Done at 3fbb1c4.