Ok, I have this done on the windows side, implementing a worklist like
GLUT has. It also nicely allows me to get rid of a bunch of hacks we
had on the windows side, e.g. to ensure that the reshape callback gets
called before the first display callback, as well as a whole bunch of
Also just like GLUT, I don't paint windows from the WM_PAINT handler
anymore, but directly using getDC, etc. This is what glut does and
allows better control over when a paint happens (otherwise i couldn't
guarantee proper timing of the display callback invocation).
I'll also be making lightweight implementations for X11 and android of
this before submitting everything (everything is nicely modularized
there, so implementation is easy), hope i get that right. More soon!
On Mon, Mar 4, 2013 at 1:09 PM, Diederick C. Niehorster
> Dear John and Nigel,
> Thank you for your replies, they were very helpful. I now see how GLUT
> does the following:
> All actions (window push/pop, resize, position, fullscreen and even
> drawing) are done in a specific order based on a list of work to be
> carried out). Callbacks are called later, on win32 in response to
> window manager messages. This allows for multiple position/resize etc
> requests to be overwrite each other within one display loop, but not
> for a pending resize to be cancelled as the callback is only called
> after the fact.
> John, on windows at least, when a user resizes with a drag operation,
> a whole bunch of size_changed and please_redraw messages come in from
> the window manager, so it doesn't realyl help against that.
> Anyway, i see what needs to be done now about the mixed situation in
> the code base (reshape is deferred to next loop iteration,
> position/show/hide/fullscreen are immediate). A similar worklist as
> glut has should be implemented instead, making everything consistent
> and deferred. This makes sense and makes things more efficient (e.g.
> on both win32 and x11, z-order changes, window position and reshape
> can all be done in one call). I'll get to work on that. And add some
> docs as to why things work the way they do. The comments in the patch
> Nigel identified are very helpful.
> John, at some point code for the glutPositionFunc callback on X11 will
> come your way. I see it should be very easy to implement, but as
> always I'll need an eye and test later ;)
> Best and thanks,
> On Mon, Mar 4, 2013 at 8:19 AM, John Tsiombikas <nuclear@...> wrote:
>> On Sun, Mar 03, 2013 at 10:48:09PM +0800, Diederick C. Niehorster wrote:
>>> Hi FreeGLUTters,
>>> I am wondering why glutReshapeWindow just sets a flag that a resize
>>> action is needed (which then gets executed upon the next redraw),
>>> while glutPositionWindow directly executes a positioning of the window
>>> without such deferring. If possible, i'd like to get rid of this extra
>>> step, i think:
>>> 1) the user's actions should directly be executed when requested, not
>>> after some delay (if no redisplay is pending, the while resize can
>>> take a long time, there have been bugs in that before)
>>> 2) Callbacks that a windwo has just been reshaped should happen in
>>> response to a message from the window manager, not later (they are
>>> also deferred until the reshape is actually executed (which leads to
>>> the funny situation where FreeGLUT gets notified of a reshape executed
>>> e.g. by mousedrag, sets the need resize flag, and then the callback
>>> only gets called later before the next redraw).
>>> On windows I see no reason why the resize needs to be like this, is
>>> there any on Linux/X11?
>> I imagine it's to avoid calling the reshape callback multiple times
>> between draw calls when the user is in the process of resizing the
>> One could argue that a properly written reshape (or any input)
>> callback will not do a lot of work and return immediately, so it
>> wouldn't necessarily be a huge issue if it did happen to be called 20
>> times in a raw. But having it deferred like this, guards against the case where
>> the user tries to recreate render targets, or even worse redraw, in the reshape
>> callback, which would produce noticable delays.
>> John Tsiombikas
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> Freeglut-developer mailing list