wxGLCanvas and wxTimer timer and GL problems
David Dynerman
7.0 and MS Windows 2000.
I'm having trouble getting timers to work in my application.
I'm developing an OpenGL application.
My wxApp derived class constructs a wxFrame derived class which then
creates a GL window derived from wxGLCanvas.
For the life of me, I can't get timers to work when the GLCanvas
window is active.
I've tried both event-based and 'deriving from wxTimer' based
approaches. Using the event-based approach I've tried using a timer
in the GL class, in the Frame class, and in the app class.
I get the same behavior across the board, no matter where I try to
handle the EVT_TIMER - and also when I derive a class from wxTimer and
override Notify()
The timer will simply not fire Notify() or the event() when the GL
window is up.
If I don't construct the GL window from my frame, the timers works
fine - all varieties.
With the GL window enabled, my wxTimer derived implementation doesn't
work while the application is running, but when you close it, the
Notify() is called a few times AFTER the GL window is destroyed (but
before the entire application closes)
Google has been no help, and I've found no documentation of this
problem elsewhere online.
Has anyone here succesfully used timer's with GLCanvas's? I don't
have all that much experience with wxWindows, so I'm not ruling out
operator error, but this seems like a bug. Perhaps the GLCanvas class
is capturing wx's timers?
Any help would be appreciated.
David
Dr.Bernhard Eck
> I'm developing an OpenGL application.
I'm also...
> My wxApp derived class constructs a wxFrame derived class which then
> creates a GL window derived from wxGLCanvas.
So far ok, my App does the same.
> I've tried both event-based and 'deriving from wxTimer' based
> approaches. Using the event-based approach I've tried using a timer
> in the GL class, in the Frame class, and in the app class.
I never try this, but based on my observations there are some problems
when the GL class is too dominant, as you also discovered.
This is how it works for me:
I derive another class from the Frame class, in which I also control the
painting of the GLcanvas (obviously you have to give this class a handle
to the GL class). This class is derived from wxTimer, and there the
Start/Stop and Notify works.
Regards,
Bernhard Eck
***********************************************
Dr. Bernhard Eck
University of Technology Aachen (RWTH)
Department of Inorganic Chemistry
Prof. Pirlet Str. 1
D-52074 Aachen
Tel.: ++49 241 809 4755
Fax: ++49 241 809 2288
http://www.rwth-aachen.de/iac/Ww/group/bernhard/
eMail: bernha...@ac.rwth-aachen.de
***********************************************
David Dynerman
Hi - Thanks for replying.
> I never try this, but based on my observations there are some problems
> when the GL class is too dominant, as you also discovered.
> This is how it works for me:
> I derive another class from the Frame class, in which I also control the
> painting of the GLcanvas (obviously you have to give this class a handle
> to the GL class). This class is derived from wxTimer, and there the
> Start/Stop and Notify works.
Yeah, I looked around some more at the OpenGL samples, and saw that
they did that, so I moved my glcanvas out from my frame and just into
my application (then used a handle as you said)
That didn't have any direct effect - my timers still didn't work.
However, then I tried this:
In my OnPaint() for my GLCanvas class I added:
wxPaintDC dc(this);
at the top. Even though I don't need a device context, some comments
I read through in the isosurf OpenGL example state that it's necessary
to clear stuff from some queue.
After doing this, the timer works nicely - although something else is
broken. Now, my GL view apparantly won't update. With that line in
it, no amount of SwapBuffers(), etc will get the GLCanvas to redraw -
it always stays with the initial setup condition.
I'm getting closer - I'll keep digging around and see what I can find.
More importantly, I'm totally documenting this once I figure it out -
so the next guy who tries wxWindows & GL can avoid some of these
headaches.
Thanks,
David
--
David Dynerman
Computer Sciences Department
University of Wisconsin at Madison
http://www.cs.wisc.edu/~dynerman/
David Dynerman
> Sorry I didn't follow the discussion, but I don't understand your
> problem ?
> Did you read wxWindows/samples/opengl/penguin or
> wxWindows/samples/opengl/sample/cube this is working very fine !
>
> I have devlop a class that link VTK (~OpenGL) with wxWindow without
> too much troubles:
>
> http://www.creatis.insa-lyon.fr/~malaterre/wxVTK/
>
> HTH
> mathieu
Hi Mathieu, thanks for replying.
I've looked at the samples, but haven't studied them extensivly - I'm
more intently using the wx Manual.
My problem isn't with GL stuff, it's more that the GL stuff is
breaking other parts of my program. In this case, my timers won't
work if I have a GL window on the screen.
I messed around with it a bit after my initial forum post, and I found
that if I added
wxPaintDC dc(this);
to my GL canvas's OnPaint() routine, the timers start working -
although then I have other problems with my GL window (see my reply in
this thread for details)
None of this was documented, and that's probobly why I'm struggling.
David
webuniversal.org - C. Planken
> so the next guy who tries wxWindows & GL can avoid some of these
> headaches.
I have to bring this up after reading that..
Last week I was thinking allong these lines, how about wx scraps the current
and gets new opengl samples which cover common used gl stuff and thus lower
the entrance barierre to wxwindows for gl oriented developers?
I was thinking about the following sample layout:
Sample 1: (basic)
Creates only a frame with a GLcanvas and shows a static triangle. The code
supports window (scene) resizing.
Sample 2: (realtime)
Like sample 1, only the triangle rotates. Perhaps the sample could offer
several solutions to build real-time OpenGL graphics applications with
wxWindows. (wxTimer?)
Sample 3: (textures)
Like sample 1, only adds a button to create a new frame based on a shared GL
context. This sample could load a few textures and shows at the same time the
contexts actually work (png, bmp..)
Sample 4: (fonts)
Perhaps a fourth which shows how to load fonts using wxWindows and OpenGL
(migh be not a good sample,
because font loading for OpenGL seems quite platform dependand)
Matthias Gondan
This might even be the most important sample. Even if there are a few
ifdefs, this example would be very
helpful. I spent a long time to find a solution for displaying text, and
what I found was a very crippled
example in the glut library.
Mike C. Fletcher
fairly complete wxPython context available from which code can be
ripped, here's the code that is wxPython specific (note that anything
which is "common OpenGL code" is factored into base-classes, so this is
*just* the wxPython-specific stuff):
Basic context setup, painting and resizing:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyopengl/OpenGLContext/wxcontext.py?rev=HEAD&content-type=text/vnd.viewcvs-markup
"Interactivity" (mouse events, keyboard events) converted to a GLUT-like
format (the particular format is OpenGLContext-specific, but these are
tasks OpenGL programmers often need to do to work with scenegraph
frameworks):
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyopengl/OpenGLContext/events/wxevents.py?rev=HEAD&content-type=text/vnd.viewcvs-markup
Using wxPython to create bitmap text:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyopengl/OpenGLContext/scenegraph/text/wxfont.py?rev=HEAD&content-type=text/vnd.viewcvs-markup
(Other trivial mechanisms, basically just making the above available to
the system):
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyopengl/OpenGLContext/wxinteractivecontext.py?rev=HEAD&content-type=text/vnd.viewcvs-markup
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyopengl/OpenGLContext/wxtestingcontext.py?rev=HEAD&content-type=text/vnd.viewcvs-markup
Built on top of (or as part of) OpenGLContext you'll find versions of
the first 8 NeHe OpenGL tutorials, demonstrations of rendering extruded
text, interaction & picking, NURBs rendering, display-lists, array-based
geometry, textures (using wxImage in the text.wxfont module, btw),
etceteras.
You could probably rip out the relevant elements fairly easily to create
NeHe-like stand-alone tutorials.
Anyway, enjoy,
Mike
webuniversal.org - C. Planken wrote:
>>More importantly, I'm totally documenting this once I figure it out -
>>so the next guy who tries wxWindows & GL can avoid some of these
>>headaches.
>>
>>
>
>I have to bring this up after reading that..
>
>Last week I was thinking allong these lines, how about wx scraps the current
>and gets new opengl samples which cover common used gl stuff and thus lower
>the entrance barierre to wxwindows for gl oriented developers?
>
>
...
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
Mike C. Fletcher
> webuniversal.org - C. Planken wrote:
...
>> Sample 4: (fonts)
>> Perhaps a fourth which shows how to load fonts using wxWindows and
>> OpenGL (migh be not a good sample,
>> because font loading for OpenGL seems quite platform dependand)
>>
> This might even be the most important sample. Even if there are a few
> ifdefs, this example would be very
> helpful. I spent a long time to find a solution for displaying text,
> and what I found was a very crippled
> example in the glut library.
It's actually just wxWindows-specific if you're willing to stick with
bitmap-only fonts (or texture-based fonts, though I haven't got a sample
for those). Basically, you can use wxWindow's font-instantiation to
find the fonts (the system-specific operation) and then just use a
wxClientDC to render the font to bitmaps (note that you _must_ do that
after you've instantiated your application!) Here's the relevant module
from OpenGLContext:
I would guess any C++ hacker could create a lean&mean version of the
same mechanism pretty easily. (If you do, you might want to make the
rendering seperate from the bitmap-creation-mechanism so that both
bitmap and texture fonts can share the code and you can allow for
caching. Given the lack of anti-aliasing, you could go a step further
and produce 1-bit images (current are 16-bit luminance-alpha) to reduce
memory overhead. (All of those are future plans for the Python module).
HTH,
Mike
webuniversal.org - C. Planken
> bitmap-only fonts
I have somewhat working code for c++, but it does not yet work for windows.
(renders only one font type). It works great for Linux.
For my app I also need font rendering and using bitmaps/textures would be the
least attractive.
So *if* any new samples will be created, it seems fonts and timers would be
the hardest, but most usefull samples.
struct gl_font
{
wxString type, fontDesc;
GLuint m_listbase;
wxFontData retData;
wxFont font;
wxColour colour;
};
gl_font viewport_mapedit;
void c_manager_fonts::choose_gl_font(gl_font *p_gl_font)
{
#if defined(__WXGTK__)
// Show the standard wxWindows 'choose font' dialog and
// create new font accordingly
wxFontData data;
data.SetInitialFont(p_gl_font->fontDesc);
data.SetColour(p_gl_font->colour);
wxFontDialog dialog(sharedCanvas, data);
if ( dialog.ShowModal() == wxID_OK )
{
glDeleteLists(p_gl_font->m_listbase, 255);
p_gl_font->retData = dialog.GetFontData();
p_gl_font->font = p_gl_font->retData.GetChosenFont();
p_gl_font->colour = p_gl_font->retData.GetColour();
Display *dpy;
XFontStruct *fontInfo; // font storage
p_gl_font->m_listbase = glGenLists(255); // storage for 96 characters.
dpy = XOpenDisplay(NULL); // default to DISPLAY env.
p_gl_font->fontDesc = p_gl_font->font.GetNativeFontInfoUserDesc();
//fontInfo.Printf(wxT("Native font info: %s"),
p_gl_font.fontDesc.c_str());
fontInfo = XLoadQueryFont(dpy,
p_gl_font->fontDesc.c_str());//fontDesc.c_str());
if (fontInfo == NULL)
{
// fontInfo = XLoadQueryFont(dpy, "fixed");
// if (fontInfo == NULL)
// printf("no X font available?\n");
}
glXUseXFont(fontInfo->fid, 0, 255, p_gl_font->m_listbase);
// free font's info
XFreeFont(dpy, fontInfo);
// close down the 2nd display connection
XCloseDisplay(dpy);
}
#endif
}
void c_manager_fonts::create_gl_font(gl_font *p_gl_font)
{
#if defined(__WXGTK__)
Display *dpy;
XFontStruct *fontInfo; // font storage
p_gl_font->m_listbase = glGenLists(256); // storage for 96 characters.
dpy = XOpenDisplay(NULL); // default to DISPLAY env.
fontInfo = XLoadQueryFont(dpy, p_gl_font->fontDesc);
if (fontInfo == NULL)
{}
glXUseXFont(fontInfo->fid, 0, 256, p_gl_font->m_listbase);
// free font's info
XFreeFont(dpy, fontInfo);
// close down the 2nd display connection
XCloseDisplay(dpy);
#endif
#if defined(__WXMSW__)
//- X11/Motif (glXUseXFont)
//- Win (wglUseFontBitmaps)
//- Mac (aglUseFont)
HDC hdc;
hdc = wglGetCurrentDC();
p_gl_font->m_listbase = glGenLists(256);
//BOOL success = font.CreateFontIndirect(&OpenGLFont);
//SelectObject(hdc, p_gl_font->fontDesc);
//SetFont(p_gl_font->fontDesc);
SelectObject(hdc, GetStockObject(SYSTEM_FONT));
wglUseFontBitmaps(hdc, 0, 256, p_gl_font->m_listbase);
#endif
}
Casey O'Donnell
One thing I've found is to basically have your OpenGL class handle the Idle
event:
EVT_IDLE(myOpenGLCanvas::OnIdle)
myOpenGLCanvas::OnIdle(wxIdleEvent& event)
{
this->Refresh(false);
}
I've also noticed that this can cause some of the other widgets to act
slow...but it was fine for what I was doing.
Good luck.
Casey
--------------------------
wxPaintDC dc(this);
at the top. Even though I don't need a device context, some comments
I read through in the isosurf OpenGL example state that it's necessary
to clear stuff from some queue.
After doing this, the timer works nicely - although something else is
broken. Now, my GL view apparantly won't update. With that line in
it, no amount of SwapBuffers(), etc will get the GLCanvas to redraw -
it always stays with the initial setup condition.
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
David Dynerman
> fairly complete wxPython context available from which code can be
> ripped, here's the code that is wxPython specific (note that anything
> which is "common OpenGL code" is factored into base-classes, so this is
> *just* the wxPython-specific stuff):
Unfortunately wxWindows seems to be most severly in need of GL-related
documentation. A brief look at Google reveals lots of Python code,
but that code does not contain the same program structures or problems
that appear when using C++.
Let's shift some of this wxPython documentation energy into general
wxWindows.
david
Mike C. Fletcher
>>If you are looking to create new OpenGL samples, OpenGLContext has a
>>fairly complete wxPython context available from which code can be
>>ripped, here's the code that is wxPython specific (note that anything
>>which is "common OpenGL code" is factored into base-classes, so this is
>>*just* the wxPython-specific stuff):
>>
>>
>
>Unfortunately wxWindows seems to be most severly in need of GL-related
>documentation.
>
Oh, I'll certainly agree to that.
>A brief look at Google reveals lots of Python code,
>
Yup, Python is pretty darn easy to code ;) :) .
>but that code does not contain the same program structures or problems
>that appear when using C++.
>
I'd disagree with that, OpenGL programming is OpenGL programming for the
most part IMO. But <shrug> to each their own opinations.
>Let's shift some of this wxPython documentation energy into general
>wxWindows.
>
Well, I won't be shifting OpenGLContext into C++ any time soon ;) (I
dislike C++, and OpenGLContext is about teaching PyOpenGL, not wxPython
specifically). But I do find that the same basic structures show up in
the Python and C++ frameworks. If it's useful to C++ peoples to see
functional wxPython GL code, cool, if not, oh well, apologies for
wasting everyone's time :) .
Have fun all,
Mike