Overlapping Fl_Gl_Windows

[dori...@gmail.com]

I have an OpenGL app with most of my fltk widgets on the left side of a rectangular window. The remainder of the window (a large square) is devoted to GL graphics.  There are 4 views of a scene that can be shown simultaneously by splitting the graphics area into 4 small fl_gl_windows, or one at a time by putting one of the views into a large fl_gl_window.  Not sure why, but in single screen mode the graphics gets corrupted when I hide fl_gl_windows that are not supposed to be seen. Specifically, GL Display Lists disappear after switching views a few times (single screen mode only). A klutzy workaround I've come up with is to never hide (i.e. ->hide) any of the views.  Seems wasteful. The graphics only work correctly if I explicitly show (i.e. ->show) all 4 windows. In single screen mode this means (?) that I'm showing 4 fl_gl_windows on top of each other, with only the last window being visible. Is fltk smart enough to know not to draw the first 3 windows?  With about 550,000 polys in the scene, I don't want to be drawing it 4 times when only once is necessary.

Thanks for your attention.

[Greg Ercolano]

On 12/29/14 23:17, dori...@gmail.com wrote:
> I have an OpenGL app with most of my fltk widgets on the left side of a rectangular window. The remainder of the window (a large square) is devoted to GL graphics. There are 4 views of a scene that can be shown simultaneously by splitting the graphics area into 4 small fl_gl_windows, or one at a time by putting one of the views into a large fl_gl_window. Not sure why, but in single screen mode the graphics gets corrupted when I hide fl_gl_windows that are not supposed to be seen. Specifically, GL Display Lists disappear after switching views a few times (single screen mode only). A klutzy workaround I've come up with is to never hide (i.e. ->hide) any of the views. Seems wasteful. The graphics only work correctly if I explicitly show (i.e. ->show) all 4 windows. In single screen mode this means (?) that I'm showing 4 fl_gl_windows on top of each other, with only the last window being visible. Is fltk smart enough to know not to draw the first 3 windows? With about 550,000
> polys in the scene, I don't want to be drawing it 4 times when only once is necessary.

Sounds like it could be platform or version specific, so please include:

* What platform + version (Mac OSX x.x.x/Linux/Windows)
* What build environment (g++, VS xxxx, Xcode x.x)
* What version of FLTK (1.3.x, or svn current..)

Try svn current esp. if Mac OSX, as there's been a lot of
development activity with opengl on OSX, switching from AGL -> Cocoa/GL.

[dori...@gmail.com]

Windows 7 Professional Service Pack 1, 64 bit, Intel Xeon(R) CPU, FLTK/Fluid 1.3.1.  Two NVIDIA Quadro FX 1800 cards (driver version 331.82)

Surprised to hear that this might be a hardware problem.  Forget about my gl problem for now.  What happens if I try to display a large fl_gl_window completely over a smaller one? The larger one is rendered second. On my system, the smaller window doesn't appear at all (which is fine by me). Is fltk smart to know not to render the smaller one?

[Greg Ercolano]

On 12/30/14 19:17, dori...@gmail.com wrote:
> Windows 7 Professional Service Pack 1

> 64 bit, Intel Xeon(R) CPU
> FLTK/Fluid 1.3.1.

You might want to retry with 1.3.3 just to see if this has been
solved already.

But read the below first.

> Surprised to hear that this might be a hardware problem.

No, I suspect it's platform specific wrt to the OS, i.e. Windows
in this case, as opposed to OSX or Linux.

> Forget about my gl problem for now. What happens if I try to display
> a large fl_gl_window completely over a smaller one?

Given your design where all four opengl widgets overlap in the
same position, I'd say hide() three of the four gl widgets,
and only show() the one you want.

If all are set to show() and they all overlap, I'd say first
that I wouldn't recommend doing that. In "general", overlapping
widgets in the same window is "bad", unless you are doing something
very specific.

That said, if you do enable them all and they all overlap, I think
all will be drawn, and I wouldn't make any assumptions about FLTK
(or opengl) doing anything to try to optimize the drawing done in
each of the overlapping widgets.

I'd only expect optimizations done if each widget were in separate
window manager windows.

[Greg Ercolano]

On 12/30/14 21:42, Greg Ercolano wrote:
>> Forget about my gl problem for now. What happens if I try to display
>> a large fl_gl_window completely over a smaller one?
>
> Given your design where all four opengl widgets overlap in the
> same position, I'd say hide() three of the four gl widgets,
> and only show() the one you want.

I see you're doing that already, but without demonstration code
it's hard to know/replicate and offer help.

Curious what happens if you not only hide() but also change
the size/position of the 'other' windows so that they're
in an unused part of the window and small (ie. 5x5 in size).

By not overlapping the show()n window with the other hidden
windows, I'm curious if that affects the problem?

I know we have multi-widget opengl demos (i.e. the cube viewer),
but perhaps this is specific to GL display lists (which I don't
think our demos use).

If so, it could be opengl driver specific, as the hardware
might not like knowing about overlapping opengl.

If not, it could be an issue in FLTK's opengl code.

I thought I recall someone else having a problem with
GL display lists that involved a small mod to FLTK, which is
why I'm suggesting you use a more recent version of fltk than 1.3.1
(i.e. 1.3.3 or svn current). However, I have a suspicion the mods
I'm thinking of were OSX specific, whereas you're using windows.
(I think that issue had something to do with adding a call to make_current())

[dori...@gmail.com]

      I see you're doing that already, but without demonstration code

    it's hard to know/replicate and offer help.

This would be too time consuming.

    Curious what happens if you not only hide() but also change
    the size/position of the 'other' windows so that they're
    in an unused part of the window and small (ie. 5x5 in size).

The first thing I tried was to 'hide' the 'other' windows. Seems to work
until I switch between windows. This is when the display lists disap-
pear.

    By not overlapping the show()n window with the other hidden
    windows, I'm curious if that affects the problem?

 

Tried it. It solves the problem. Any situation that calls for all four
windows to be displayed works, whether or not they partially over-
lap, or completely overlap.

Back to the situation where I only want to see one window.  I put print
statements at the beginning of all 4 of my windows to see if the routines
were called even when they completely overlapped.  They were. Since
I know which window is supposed to be visible, now I'm 'returning' out
of the hidden windows before any graphics is done. This has definitely
increased display speed in the visible window. So I assume that render-
ing completely hidden in fl_gl_windows does takes place.

I believe the Display lists are somehow going out of scope when I
don't call all 4 fl_gl_windows. Everything seems to work fine if I call
all of the windows even if I simply 'return' out of the hidden windows
before any graphics is performed. This is a good enough work around
for my purposes.

Thanks for the input.

[dori...@gmail.com]

FWIW - The problem I was having with disappearing OpenGL display lists was caused by using FLTK gl_draw(s).  I've had lots of problems with gl_draw and glutBitmapCharacter in the past. When my applications get large, both of those routines stop working. However, I've never seen GL graphics get corrupted by using these routines. When I started developing this particular app, I did not expect it to get 'large' enough to run into these problems.  And there was no problem until I added 50 OpenGL display lists, rendering 575,000 polys to the app. The hint that led me to find the problem is that some of the labels in the OpenGL scenes were not showing up correctly when I used the display lists (there's a compile option in my app to render the objects with or without display lists). I'm now using my own raster and polygonal fonts, which solved the problem. Is it possible that glutBitmapCharacter and gl_draw over-write memory? Whatever, this whole problem was caused by laziness on my part.  Should have gone with my own font systems from the beginning.