wxGLCanvas: empty (default) constructor
mathieu
One of my user (wxVTK) just recently send me the following email:
http://sourceforge.net/mailarchive/forum.php?thread_id=31530003&forum_id=41789
...
error: no matching function for call to `wxGLCanvas::wxGLCanvas()'
...
I had a quick look at the source of gtk/glcanvas.cpp and I discover
that indeed the default empty constructor was removed. Any reason why ?
Thanks
Mathieu
Julian Smart
but I can think of no
good reason that the default constructor was omitted. We ought to add it
back. Sorry about this.
Regards,
Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-u...@lists.wxwidgets.org
For additional commands, e-mail: wx-use...@lists.wxwidgets.org
Carsten Fuchs
Julian Smart wrote:
> Darn. A revised implementation of wxGLCanvas was committed 4 months ago
> but I can think of no
> good reason that the default constructor was omitted. We ought to add it
> back. Sorry about this.
Sorry for my late reply, but I don't think the default ctor should be added back - just use one of
the other explicit ctors (the default ctor doesn't make much sense for wxGLCanvas anyway).
Here is the link to the relevant patch whose application caused the removal of the ctor "as a side
effect": http://sourceforge.net/tracker/index.php?func=detail&aid=1322118&group_id=9863&atid=309863
It was applied by Robert Röbling, who also explains in a comment why he removed the ctor (which was
not originally a feature of the patch, but is meaningful in the same context.)
Best,
Carsten
--
Ca3D - Engine http://www.Ca3D-Engine.de
Carsten Fuchs http://www.Ca3D-Engine.de/c_Carsten.php
Julian Smart
> Hi all,
>
> Julian Smart wrote:
>> Darn. A revised implementation of wxGLCanvas was committed 4 months
>> ago but I can think of no
>> good reason that the default constructor was omitted. We ought to add
>> it back. Sorry about this.
>
> Sorry for my late reply, but I don't think the default ctor should be
> added back - just use one of the other explicit ctors (the default
> ctor doesn't make much sense for wxGLCanvas anyway).
>
> Here is the link to the relevant patch whose application caused the
> removal of the ctor "as a side effect":
> http://sourceforge.net/tracker/index.php?func=detail&aid=1322118&group_id=9863&atid=309863
>
> It was applied by Robert Röbling, who also explains in a comment why
> he removed the ctor (which was not originally a feature of the patch,
> but is meaningful in the same context.)
of the constructor. Our usual convention is to allow 2-step construction
of windows (for example, if you want to set an extended style before
calling Create), which now isn't possible for wxGLCanvas. Any particular
reason why it doesn't make sense for wxGLCanvas specifically?
Thanks,
Julian
Carsten Fuchs
> Having read the comments I still don't see any real reason for removal
> of the constructor. Our usual convention is to allow 2-step construction
> of windows (for example, if you want to set an extended style before
> calling Create), which now isn't possible for wxGLCanvas. Any particular
> reason why it doesn't make sense for wxGLCanvas specifically?
Hi Julian,
well, Roberts reason was "I removed the empty constructor for
wxGLCanvas, which only existed for wxGTK", i.e. it apparently never existed under wxMSW (and other
ports?).
Another (probably stronger) reason is the question on whether the default ctor should or should not
create an implicit wxGLContext resource for use with the wxGLCanvas. Once the decision is made (I
highly recommend the latter, i.e. to *not* create an implicit wxGLContext), there is indeed no good
reason to not add the default ctor back.
(Iirc, respectively http://www.wxwidgets.org/manuals/stable/wx_wxglcanvas.html , the old ctor did
not create such an implicit wxGLContext either, so the behaviour would remain consistent. However,
it would be interesting to learn if and how the OP actually used it. It seems to me that the old
default ctor did not create a functioning wxGLCanvas at all, but then I never tried.)
In any case, the behaviour of the default ctor wrt. the wxGLContext should be carefully documented
at http://www.wxwidgets.org/manuals/stable/wx_wxglcanvas.html , as this is the key issue most of the
last patch was about.
Best regards,
Carsten
--
Ca3D - Engine http://www.Ca3D-Engine.de
Carsten Fuchs http://www.Ca3D-Engine.de/c_Carsten.php
---------------------------------------------------------------------
mathieu
> Julian Smart wrote:
> > Having read the comments I still don't see any real reason for removal
> > of the constructor. Our usual convention is to allow 2-step construction
> > of windows (for example, if you want to set an extended style before
> > calling Create), which now isn't possible for wxGLCanvas. Any particular
> > reason why it doesn't make sense for wxGLCanvas specifically?
>
> Hi Julian,
> well, Roberts reason was "I removed the empty constructor for
> wxGLCanvas, which only existed for wxGTK", i.e. it apparently never existed under wxMSW (and other
> ports?).
>
> Another (probably stronger) reason is the question on whether the default ctor should or should not
> create an implicit wxGLContext resource for use with the wxGLCanvas. Once the decision is made (I
> highly recommend the latter, i.e. to *not* create an implicit wxGLContext), there is indeed no good
> reason to not add the default ctor back.
> not create such an implicit wxGLContext either, so the behaviour would remain consistent. However,
> it would be interesting to learn if and how the OP actually used it. It seems to me that the old
> default ctor did not create a functioning wxGLCanvas at all, but then I never tried.)
>
> In any case, the behaviour of the default ctor wrt. the wxGLContext should be carefully documented
> last patch was about.
Thanks for the detailed explanation. I have tried again my wxVTK code
using wxWindow and the GTK2.8.0 port. Everything seems to be working
fine now. So whatever issues I had in the past that make me use a
wxGLCanvas instead of a wxWindow is gone.
http://wxvtk.sourceforge.net/
...
1.2 (31 January 2007)
* wxVTK requires CMake 2.4.5 now. This should solve the issue for
bug #1611004,
* Support wxGTK 2.8.0. wxGTK will now use wxWindow in wxGTK 2.8.0
and above. Thus you do not need to compile with opengl support anymore
now,
* Fix compilation on wxX11 (Thanks to David Akers for report &
patch).
...
Thanks
-M
Carsten Fuchs
mathieu wrote:
> fine now. So whatever issues I had in the past that make me use a
> wxGLCanvas instead of a wxWindow is gone.
>
> * Support wxGTK 2.8.0. wxGTK will now use wxWindow in wxGTK 2.8.0
> and above. Thus you do not need to compile with opengl support anymore
> now,
I'm a bit confused: even though you don't use OpenGL with your project, you used a wxGLCanvas
before? Or vice versa, you do use OpenGL and it happens to work within a regular wxWindow now (where
a wxGLCanvas used to be used)? If the latter, that's certainly not portable...
Best,
mathieu
> Hi Mathieu,
>
> mathieu wrote:
> > fine now. So whatever issues I had in the past that make me use a
> > wxGLCanvas instead of a wxWindow is gone.
>
> > * Support wxGTK 2.8.0. wxGTK will now use wxWindow in wxGTK 2.8.0
> > and above. Thus you do not need to compile with opengl support anymore
> > now,
>
> I'm a bit confused: even though you don't use OpenGL with your project, you used a wxGLCanvas
> before? Or vice versa, you do use OpenGL and it happens to work within a regular wxWindow now (where
> a wxGLCanvas used to be used)? If the latter, that's certainly not portable...
Carsten,
Do you have some time to answer a couple of question then ? I am
working on wxVTK. Basically it creates a wxWindow, extract the XWindow
pointer and pass it to VTK for rendering. It is working perfectly when
using wxGLCanvas (pre 2.8.0 because of previously described issue).
But if I now switch to wxWindow I can see a couple of minor issues:
- When the first OnPaint occur the image is not displayed correctly.
- When I move another window on top of my wxVTK window and then remove
it. The display is scrambled (not redrawn correctly).
If you are an expert in the difference in between wxwindow (MSW) and
wxwindow (GTK) (which seems to be the same difference as a
wxGLCanvas(GTK) and wxwindow(GTK)). Could you please let me know how
to deal with them ?
For more info:
http://wxvtk.cvs.sourceforge.net/*checkout*/wxvtk/wxVTK/src/wxVTKRenderWindowInteractor.h
http://wxvtk.cvs.sourceforge.net/*checkout*/wxvtk/wxVTK/src/wxVTKRenderWindowInteractor.cxx
Or the python version which exhibit the same issues:
http://www.vtk.org/cgi-bin/viewcvs.cgi/*checkout*/Wrapping/Python/vtk/wx/wxVTKRenderWindowInteractor.py
Thanks in advance,
Mathieu
Carsten Fuchs
> (Iirc, respectively
> http://www.wxwidgets.org/manuals/stable/wx_wxglcanvas.html , the old
> ctor did not create such an implicit wxGLContext either, so the
> behaviour would remain consistent. [...]
Ohhh, I'm very sorry, the link above was actually meant to be
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/gtk/glcanvas.h.diff?r1=1.15&r2=1.16
showing the original empty ctor.
As one can see, in Mathieus case it should not make a difference whether he uses a wxGLCanvas with
default ctor or a wxWindow.
Best,
Carsten Fuchs
mathieu wrote:
> Do you have some time to answer a couple of question then ? I am
> working on wxVTK. Basically it creates a wxWindow, extract the XWindow
> pointer and pass it to VTK for rendering.
What does that ("rendering") mean? OpenGL rendering or something else?
> It is working perfectly when
> using wxGLCanvas (pre 2.8.0 because of previously described issue).
> But if I now switch to wxWindow I can see a couple of minor issues:
> - When the first OnPaint occur the image is not displayed correctly.
> - When I move another window on top of my wxVTK window and then remove
> it. The display is scrambled (not redrawn correctly).
Well, that does not sound releated to whether you use a wxGLCanvas or a wxWindows. The old default
ctor of wxGLCanvas for wxGTK can be seen here:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/gtk/glcanvas.h.diff?r1=1.15&r2=1.16
For your case, it seems to add nothing essential over a regular wxWindow, so I guess it cannot be
the reason for such problems.
> If you are an expert in the difference in between wxwindow (MSW) and
> wxwindow (GTK) (which seems to be the same difference as a
> wxGLCanvas(GTK) and wxwindow(GTK)). Could you please let me know how
> to deal with them ?
Sorry, I'm not an expert in the differences between wxMSW and wxGTK, especially my GTK related
knowledge is little. Also, I don't think that wxWindow (wxMSW) relates to wxWindow (wxGTK) as
wxGLCanvas (wxGTK) relates to wxWindow (wxGTK) or wxGLCanvas (wxMSW).
The only exception wrt. a close relationship in the context of this (mailing-)thread occurs/occurred
with the default (empty) ctor as shown in the above link.
> For more info:
> http://wxvtk.cvs.sourceforge.net/*checkout*/wxvtk/wxVTK/src/wxVTKRenderWindowInteractor.h
> http://wxvtk.cvs.sourceforge.net/*checkout*/wxvtk/wxVTK/src/wxVTKRenderWindowInteractor.cxx
I've had a look at those, but they don't reveal anything about your rendering (is it done with
OpenGL or another way?). Also, if you use OpenGL, why don't you try one of the non-empty ctors of
wxGLCanvas, see http://www.wxwidgets.org/manuals/stable/wx_wxglcanvas.html for details.
If you *don't* use OpenGL, I suggest that the recent rendering issues that you observe with wxWindow
(where wxGLCanvas used to be used) are not related to wxGL* issues, but to something else.