Windows GLUT: post_update_main_gfx "post" happens before execute_callback

[m-7761]

Example 4 has a lights enable/disable checkbox that appears to not work. I think it's because glutPostRedisplay is actually rendering before it returns from the call. That's a really dumb design if so. But I can't explain it any other way.

I tried putting the "post" on a timer, and it didn't work with any values less than 100ms.

So, what I recommend is to call post_update_main_gfx twice (it's called once by output_live) by adding another call to the end of execute_callback.

[nigels-com]

Seems to be working fine on mainline branch. Perhaps it's some sort of side-effect of your rework?

[m-7761]

See "Nvidia GLUT" in subject line. Things have to work with every GLUT variant on every platform pretty much.

[nigels-com]

A link to the specific GLUT source or binary, 32-bit vs 64-bit, Windows version, etc would be helpful for this.

[m-7761]

It's absolutely not worth your time, but here (https://github.com/mick-p1982/glui/blob/master/bin/Win32/glut32.lib) you go. It's from the Cg binaries.

[m-7761]

https://github.com/libglui/glui/blob/master/glui_checkbox.cpp#L85

This code calls set_int_val that is overridden at the bottom of the file:

https://github.com/libglui/glui/blob/master/glui_checkbox.cpp#L196

That code calls output_live which generates a glutPostRedisplay. Then it returns and the code calls execute_callback:

https://github.com/libglui/glui/blob/master/glui_checkbox.cpp#L94

That's pretty much unavailable unless the control were to directly assign int_val and only call set_int_val after the callback.

So the user code's callback procedure takes action after glutPostDisplay and it so its changes to the GL state have no effect on the displayed image.

If GLUT puts a "paint" event on an event stack that only gets processed in the "message loop" after all of this code returns control to GLUT then it will draw the display after the callback's changes.

In this case that doesn't happen. I think that calling glutPostDisplay or glutTimerFunc may be signalling to GLUT that it's free to empty its message queue before returning. Somehow even putting it in a timer doesn't help.

It seems pretty responsive. You'd think that if the API calls took so long to return it wouldn't be so. I just tested it to be sure the problem is still there.

I think what might be happening is the GLUT implementation is interpreting SetWindow as an opportunity to flush itself, since the windows are changing. It doesn't perhaps envision a case where you have a window cooperating with another window as GLUI does.

EDITED: If a GLUI doesn't work with every GLUT out there then it's garbage and should die instead of wasting peoples time. It's not rocket science. It's why having an alternative to GLUT is a good escape plan.

[nigels-com]

I'll try it on Windows to confirm.

[nigels-com]

Worked on Windows 10 for me. Possibly a bug in the mick-p1982 fork?

[m-7761]

It's not the kind of thing that can be caused by user code. You probably didn't link to the correct library. But depending on how GLUT is implemented it can be something about Win32 too. I don't like that the problem exists, but it exists.

[m-7761]

What you can do is download said fork and build it with this (https://github.com/mick-p1982/glui/blob/master/src/glui_control.cpp#L742) line disabled. Then see what happens. If you don't believe it, then trace the code.

It literally just does set_int_val and execute_callback back-to-back. There's no space for any other interpretation.

EDITED: The MSVC folder has a Debug project that links to the static library that exhibits this behavior.

[nigels-com]

This isn't the correct forum for bugs concerning your GLUI fork. Closing.

[m-7761]

This isn't the correct forum for bugs concerning your GLUI fork. Closing.

Dirt bag.

[nigels-com]

To draw your attention to the GitHub terms of service: https://help.github.com/en/articles/github-terms-of-service#c-acceptable-use

While using GitHub, you agree that you will not under any circumstances: harass, abuse, threaten, or incite violence towards any individual or group, including GitHub employees, officers, and agents, or other GitHub Users;

Please keep things polite and friendly here.