Re: [Freeglut-developer] Release schedule?

[Eric S. <er...@sa...>]

Stephen J Baker said:
>
> The main question for me is:
>
>
>    "Can we fix the menu issue and still have a reliable
>     release before RedHat have to make a go/no-go decision?"
>
>
> * If the answer is "No" then we should just continue to fix up
>    2.0.0 (without the menu fix) and debate whether we want RedHat
>    to release it or not:
>
>         + If we decide NOT to let them release 2.0.0 (because it
>           doesn't have the menu fix) - then they'll probably not
>           release GLUT either - which is "A Bad Thing" for both
>           GLUT and freeglut.
>
>         + If we decide to say "The heck with it - go for broke" and
>           ask RedHat to release freeglut 2.0.0 - DESPITE the menu
>           problem - then we are taking a chance.  Will the fact that
>           freeglut doesn't run all the programs that GLUT used to run
>           cause people to say "Yuk - freeglut is a piece of crap - give
>           us GLUT back!" - or will they simply flood us with bug reports?
>
> * If the answer is "Yes" then we should make sure that happens,
>    and it really doesn't matter whether we do a 2.0.0 release
>    and then almost immediately replace it with 2.0.1 - or whether
>    we postpone 2.0.0 to allow the menu issue to be fixed.
>
> I can't answer the first question because I don't know when RedHat's
> "drop dead date" is - and because nobody has specifically volunteered
> to attack the Menu problem and nail it in a timely manner.
>
> FYI, the menu problem is this:
>
>    In GLUT, menu's are rendered in the native windowing system so they
>    are not seen by OpenGL and don't participate in double-buffering.
>
>    In freeglut, menu's are rendered in OpenGL - which means that they
>    interact badly with the 3D rendering going on in the main part of
>    the window under certain conditions.
>
> The presumed best fix is to have the menu create it's own little
> border-less, no-decoration, always-on-top window with it's own
> OpenGL rendering context.  Then it can double-buffer swap
> independently of the application and has it's own set of texture
> handles, glEnable/glDisable settings, etc. The problem goes away.

I'm not sure of the feasability on fixing the menu problem, but I say our
first major release after so long should be as unbroken as possible, just
so our latest impression will be a good one.

I'm not much of an OpenGL programmer (hence why I'm still playing with my
candlelight program, though not too much), otherwise I'd try hacking at
this.

-sandalle

-- 
PGP Key Fingerprint:  FCFF 26A1 BE21 08F4 BB91  FAED 1D7B 7D74 A8EF DD61
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61

Eric Sandall                     |  Source Mage GNU/Linux Developer
er...@sa...                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/