Closed GoogleCodeExporter closed 9 years ago
That should be OnPaint, not OnDraw.
I get the following error if I do not set the context in OnPaint:
File "C:\Users\me\Python33\lib\site-packages\visvis\core\baseTexture.py", line
228, in Enable
gl.glBindTexture(self._texType, self._texId)
File "errorchecker.pyx", line 50, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError (src\errorchecker.c:945)
OpenGL.error.GLError: GLError(
err = 1282,
description = b'invalid operation',
baseOperation = glBindTexture,
cArguments = (GL_TEXTURE_1D, 1)
But only for figures with mesh objects?
Original comment by geith.gm...@gmail.com
on 15 Oct 2013 at 11:16
Thanks for this contribution, Keith.
Probably the previous version did make the context current automatically. It
seems you have to manage the openGL context yourself now, so it kind of makes
sense.
The API seems quit different so its probably best to make a new backend for
this. Is there a way to detect whether phoenix is used or the old wx?
Original comment by almar.klein@gmail.com
on 16 Oct 2013 at 8:54
Almar:
The documentation can be found here:
http://wxpython.org/Phoenix/docs/html/main.html and nightly builds here:
http://wxpython.org/Phoenix/snapshot-builds/
I no longer have the older wxPython, but with Phoenix, wx.version() returns the
following string:
3.0.0.0-r74991 msw (phoenix)
Since both the old and new modules are named wx adding it as a backend seems
like it will be a little more work. I wasn't sure how best to do that.
There are several API changes that I had to make to the original backend_wx.py.
particularly in Class App._ProcessEvents.
I'm not sure if I caught everything and I will continue to use it and look for
failures.
Original comment by geith.gm...@gmail.com
on 16 Oct 2013 at 3:06
Aha, so it is essentially the same toolkit, but just a newer version. Checking
for "int(wx.version()[0]) >= 3" should probably be robust.
So do you think it is feasible to create a single wx backend module that has
some if-statements in order to deal with both versions?
Original comment by almar.klein@gmail.com
on 16 Oct 2013 at 9:06
Its possible to have a common backend module, but I was thinking it might be
best to have two and put the module checking code in backends.__init__.py
It may be easier to maintain as separate modules, especially since Phoenix is
still a work-in-progress.
I looked at backends.__init__.py briefly and it wasn't clear how to properly
add a backend, and in this case, where to check for module version.
Original comment by geith.gm...@gmail.com
on 17 Oct 2013 at 2:38
The problem with having separate modules is that we would have two backends
that are both based on the package "wx". For one, this forces the user to
select wx 3.0 using vv.use('wx3') or vv.use('wxphoenix') or something, which
becomes problematic when wx 3.0 becomes the default. Further, this would make
some other steps in backends.__init__.py more complicated with explicit checks
for wx and its version.
So if it is not too much of a hassle, I would prefer a single module.
Original comment by almar.klein@gmail.com
on 18 Oct 2013 at 7:43
Mmm, another possibility (sort of a hybrid) is to have one backend_wx.py that
checks the version of wx and then imports * from _backend_wx2 or _backend_wx3.
Original comment by almar.klein@gmail.com
on 18 Oct 2013 at 7:45
Almar:
How about this version? Its a single wx module, has two GLWidget classes with
the right one selected in Figure and two App._ProcessEvents with the right one
set in App.__init__.
It works under wxPython Phoenix, someone would need to test it for the older
wxPython.
Original comment by geith.gm...@gmail.com
on 18 Oct 2013 at 3:30
Attachments:
That sounds like a good approach! I shall test it next week.
Original comment by almar.klein@gmail.com
on 19 Oct 2013 at 8:19
Do I understand it correctly that Phoenix is a codename for 3.x? Is it perhaps
better to test ``wx.VERSION > (3,)``?
Original comment by almar.klein@gmail.com
on 22 Oct 2013 at 8:16
I needed to make one small change in the app instance, but for the rest it
worked.
I did refactore the code a bit. The GLWidgetPhoenix now inherits from GLWidget,
since it only needs to overload the paint and focus methods. I checked that the
other methods are all the same, but can you test whether it still works?
http://code.google.com/p/visvis/source/browse/backends/backend_wx.py
Original comment by almar.klein@gmail.com
on 22 Oct 2013 at 8:49
There are older versions of Phoenix prior to 3.x
Original comment by geith.gm...@gmail.com
on 22 Oct 2013 at 4:48
Almar:
your version where GLWidgetPhoenix inherits from GLWidget works great.
I will try to contact Robbin Dunn about the best way to identify Phoenix for
selecting the appropriate API.
Original comment by geith.gm...@gmail.com
on 22 Oct 2013 at 5:35
Good idea
Original comment by almar.klein@gmail.com
on 22 Oct 2013 at 9:09
Here's the response I got from Robbin:
We could use: 'phoenix' in wx.PlatformInfo
Keith Smith wrote:
> The question we had is: will the string "phoenix" always be included in
> the return from wx.version or is there a better way to tell if one is
> using the Phoenix module over classic?
No, it may not always be in the wx.version() string, but it will always
be in the wx.PlatformInfo tuple.
--
Robin Dunn
Software Craftsman
http://wxPython.org
Original comment by geith.gm...@gmail.com
on 24 Oct 2013 at 2:32
I changed it accordingly. Could you do a last check?
Original comment by almar.klein@gmail.com
on 25 Oct 2013 at 7:25
Tested latest version with 'phoenix' in wx.PlatformInfo switch.
Works correctly.
Thanks!
Original comment by geith.gm...@gmail.com
on 25 Oct 2013 at 5:05
Original comment by almar.klein@gmail.com
on 26 Oct 2013 at 12:10
Original issue reported on code.google.com by
geith.gm...@gmail.com
on 15 Oct 2013 at 11:10Attachments: