#31 First visiblity comes after first reshape.

[Richard Rauch]

This is a very low priority bug, since I am not sure
that it really affects anyone, the detail falls outside
of the GLUT spec., and it is possible that GLUT was not
consistant on this point anyway.

In GLUT on X11, the very first event sent to an
application is a visibility, I believe. On freeglut,
the fist event is a Reshape. Here
are corresponding initial outputs from a toy
application of mine:

/~~~ with GLUT

Main window visible: 1
Reshaped main window: 500, 500
Redisplay called.
Timer called (1)

\___ with GLUT

/~~~ with freeglut

Reshaped main window: 500, 500
Main window visible: 1
Redisplay called.
Timer called (1)

\___ with freeglut

(Timer events were set to be called every second.)

This won't matter much for most applications, but it is
conceivable that the sequence of callbacks will matter
in some cases, so if we can easily match GLUT, we should.

(Can someone confirm with WIN32 what happened with old
GLUT?)

[Richard Rauch]

Source for the indicated event-generator program. (Links gainst either GLUT or freeglut.)

[Richard Rauch]

Logged In: YES
user_id=854844

I apparently forgot to "check" the box to indicate that the
file I selected/indicated was in fact the file that I wanted
to attach.

The attached file is "main.cxx", a C++ program that can be
built against either GLUT or freeglut, and which produces
the output excerpted in the bug report.

[Nigel Stewart]

Logged In: YES
user_id=338692

In my humble opinion it is more logical for the application
to receive the visibility event _before_ the resize event.
There doesn't seem much point in sending or handling
resize events for invisible windows.

Here is some diagnostic output for GLUT as distributed
with Cygwin on Win32....

--------------

Cygwin with GLUT:

nigels@zooropa /m/tmp/test$ g++ main.cxx -lglut32 -lglu32
-lopengl32
nigels@zooropa /m/tmp/test$ ./a.exe
Main window visible: 1
Main window entered: 1
Glide motion in main window: 292, 223
Reshaped main window: 500, 500
Redisplay called.
Timer called (1)
Timer called (5)
Timer called (25)
Timer called (125)

MingW32 with GLUT:

nigels@zooropa /m/tmp/test$ g++ main.cxx -mno-cygwin
-lglut32 -lglu32 -lopengl32
nigels@zooropa /m/tmp/test$ ./a.exe
Main window visible: 1
Main window entered: 1
Glide motion in main window: 223, 235
Reshaped main window: 500, 500
Redisplay called.
Timer called (1)

[Richard Rauch]

Logged In: YES
user_id=854844

I agree that the GLUT behavior makes more sense. Does GLUT
on CygWIN use X11? I'm nto familiar with MingW32 at all.

Anyway, thanks for testing!

[Nigel Stewart]

Logged In: YES
user_id=338692

Cygwin can either use win32 OpenGL or Mesa via X11..

Cygwin to link with win32 GLUT, GLU and GL:

g++ main.cxx -lglut32 -lglu32 -lopengl32

To link with XFree GLUT, (Mesa) GLU and (Mesa) GL:

g++ main.cxx -lglut -lGLU -lGL -L/usr/X11R6/lib

[Krzysztof Pawlik]

Logged In: YES
user_id=335861

As for freeglut:

krzysiek:krzysiek# g++ main.cxx -o main -lfreeglut -lGL
krzysiek:krzysiek# ./main
Loading required GL library /usr/X11R6/lib/libGL.so.1.2
disabling TCL support
Main window visible: 1
Redisplay called.
Main window entered: 1
Reshaped main window: 500, 500
Redisplay called.
Timer called (1)
Timer called (5)

First two lines come from drivers for my video card.
Everything's ok on Linux MDK 9.2.

[Nigel Stewart]

Logged In: YES
user_id=338692

Is it time to mark this as resolved?

[Richard Rauch]

Logged In: YES
user_id=854844

As far as I can see, nothing has changed. I resynced my
copy of the current CVS and re-built my "events" test
program. It still does the reshape before the first
visibility. (I thought that nelchael_kp was just
re-affirming my UNIX_X11 tests. Sorry for misreading. Mea
culpa.)

To nelchael_kp: Which freeglut did you use? Since GNU/LINUX
and NetBSD both use the UNIX_X11 branch, behavior should be
identical to what I observed on my NetBSD box. However, I
was checking against the current CVS repository. It is
possible that past releases did not exhibit
this behavior.

[Krzysztof Pawlik]

Logged In: YES
user_id=335861

2.2.0

[Richard Rauch]

Logged In: YES
user_id=854844

I don't think that anything changed in this regard since
then, but can you try current, anyway?

[Richard Rauch]

Logged In: YES
user_id=854844

Okay, I think that I see the problem. Duh. (^&

CreateNotify: and ConfigureNotify: events are treated identically. This is sort-of necessary for sub-windows (since X won't generate an initial configure event; but GLUT sends reshape callbacks to *every* window upon creation, and it is easy for apps to rely upon that).

The first event that you get for your window should be a CreateNotify: event, which should generate a reshape callback.

We can work around this by storing the reported new size and setting a flag---then handling this during the fgDisplayAll() code. (WIN32 is already doing this, though I have some disagreements with some of the details of the WIN32 branch. We can reuse the same variables and get rid of the State.Old{Width,Height} variables, I think.)

If there are no objections, I guess I'll put this on my plate.

[Richard Rauch]

Logged In: YES
user_id=854844

Last I tried, this was still a bug with freeglut.

However, as I am no longer in a position to resolve it, can
someone with access please reassign it, either to nobody
or to themselves?

Thanks.

[Richard Rauch]

Logged In: YES
user_id=854844

Is *any* freeglut developer actually reading this?

I would find it ironic if the only people doing freeglut support are
OpenGLUT developers. (Mostly Nigel and myself.)

Yes, I could ask that it be unassigned, via one of the lists. But
I've been using the lack of responsiveness on this subject to
be a metric of freeglut's commitment to support.

Well, I'll try reassigning it myself. Just for giggles. If that doesn't
work, I'll let it sit a while longer.

[Nigel Stewart]

Logged In: YES
user_id=338692

Richard,

Is this fixed over in OpenGLUT land?

Shall we just do some cut and paste and stop having
our OpenGLUT chatter on the FreeGLUT bug reports? :-)

Nigel

[Richard Rauch]

Logged In: YES
user_id=854844

No, it has never been fixed. Since we started OpenGLUT, I've
spent a lot of time on administrivia and comparatively little
time on bug-fixes like this issue. It was still a problem
the last time that I checked.

As for cutting and pasting, I can see rationales for both
ways. Having, and closing, bug reports on OpenGLUT would
be good. On the other hand, as we still have a lot of
common issues with freeglut, it may be more helpful for
users to see both projects' responses to bug reports in
a single place.

I guess if you want to copy-and-paste to OpenGLUT, I wouldn't
mind. (^&

[Richard Rauch]

Logged In: YES
user_id=854844

Re. cutting and pasting:

Since freeglut is not doing much with their bug database,
and it woudl be helpful to have a list of bugs that OpenGLUT
has resolved (and to be able to *close* them after we
fix the issue), I am increasingly favoring the notion of
pasting bug reports from freelut to OpenGLUT.

I have put one in over on OpenGLUT, with a reference to
the corresponding freeglut bug. I think that I have fixed
the bug in OpenGLUT, but would like to see an OpenGLUT
release with the fix, then direct the poster to try the
current OpenGLUT release (0.6.3 or whatever it winds up
being).

[rcmaniac25]

Talk about bringing a ticket back from the dead...

So this is still an issue. Or at least could be if order of events is expected.

I did not test with GLUT, but with freeglut, between Windows (Windows 10 1607) and X11 (Ubuntu 16.04.02 LTS), there is a difference.

Windows: visibility, reshape, redisplay, timer, ...
X11: reshape, visibility, visibility, visibility, redisplay, timer, ...

Running in debug (modified timer demo with Richard's sample), I see this:

$ ./timer
freeglut (./timer): ConfigureNotify: event=0x0, window=0x6a00009, (x,y)=(-1,-1), (width,height)=(300,300), border_width=0, above=0x0, override_redirect=False
freeglut (./timer): ConfigureNotify: event=0x0, window=0x6a00005, (x,y)=(-1,-1), (width,height)=(300,300), border_width=0, above=0x0, override_redirect=False
freeglut (./timer): ConfigureNotify: event=0x0, window=0x6a00002, (x,y)=(250,250), (width,height)=(500,500), border_width=0, above=0x0, override_redirect=False
Reshaped main window: 500, 500
freeglut (./timer): ReparentNotify: event=0x6a00002, window=0x6a00002, parent=0x1eef789, (x,y)=(0,0), override_redirect=False
freeglut (./timer): ConfigureNotify: event=0x6a00002, window=0x6a00002, (x,y)=(250,250), (width,height)=(500,500), border_width=0, above=0x0, override_redirect=False
freeglut (./timer): ConfigureNotify: event=0x6a00002, window=0x6a00002, (x,y)=(250,250), (width,height)=(500,500), border_width=0, above=0x0, override_redirect=False
freeglut (./timer): MapNotify: event=0x6a00002, window=0x6a00002, override_redirect=False
freeglut (./timer): VisibilityNotify: window=0x6a00002, state=VisibilityUnobscured
Main window visible: 1
freeglut (./timer): Expose: window=0x6a00002, (x,y)=(0,0), (width,height)=(500,500), count=0
freeglut (./timer): VisibilityNotify: window=0x6a00002, state=VisibilityPartiallyObscured
Main window visible: 1
freeglut (./timer): ConfigureNotify: event=0x6a00002, window=0x6a00002, (x,y)=(250,278), (width,height)=(500,500), border_width=0, above=0x0, override_redirect=False
freeglut (./timer): VisibilityNotify: window=0x6a00002, state=VisibilityUnobscured
Main window visible: 1
freeglut (./timer): Expose: window=0x6a00002, (x,y)=(490,0), (width,height)=(10,462), count=1
freeglut (./timer): Expose: window=0x6a00002, (x,y)=(0,462), (width,height)=(500,38), count=0
Redisplay called.
Timer called (1)
Timer called (5)
Timer called (25)
Timer called (125)
Timer called (625)
Timer called (3125)
Timer called (15625)
Timer called (78125)
Timer called (390625)
Timer called (1953125)
Timer called (9765625)
Timer called (48828125)
Timer called (244140625)
Timer called (1220703125)
freeglut (./timer): ClientMessage: window=0x6a00002, message_type=302, format=32, data=( 0000012c 0329d6e3 00000000 00000000 00000000 )

Since it seems we simply recieve the event and invoke the callback, and from what I've read, X11 has no enforced event order on window creation. Thus, I don't know if this can be fixed without adding window state to X11 windows. If it can't, I don't know if we want to fix it. Seems nobody has indicated this as an issue since 2004 and I'm just going through the open issues to see what still needs fixing.

[Diederick C. Niehorster]

Thanks for bringing it up! As this hasn't come up again in over ten yers, i think its safe to close this.

[rcmaniac25]

I think I realized why this is happening. I'm looking into a different task and was going through fgPlatformOpenWindow in fg_window_x11.c and noticed we create and push a ConfigureNotify event directly after creating the window so we "Fake configure event to force viewport setup even with no window manager." ConfigureNotify events invoke a position and reshape callbacks (if they aren't default values).

Thus, my guess: by sending our own ConfigureNotify, we end up causing a reshape notification before any native window events. As I've never developed for X11, I don't know if removing that manual notification could result in never getting a reshape from the native system, but just an FYI on this ticket.