google-code-export / visvis

Automatically exported from code.google.com/p/visvis
Other
1 stars 1 forks source link

New Backend for wxPython Pheonix ver 3.0.0.0 #78

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Alamar:

Here's a back end that seems to work with the new wxPython Pheonix ver 3.0.0.0

This seems to work on Python 3.3.2 with wxPython Pheonix 3.0.0.0

I had to explicitly set the glContext for OnFocus and OnDraw events.

I might not need it on OnDraw, but haven't done much testing

If anyone has backend experience and/or a similar set-up and can test it I'd 
appreciate the feedback.

Thanks,
Keith

Original issue reported on code.google.com by geith.gm...@gmail.com on 15 Oct 2013 at 11:10

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
There are older versions of Phoenix prior to 3.x

Original comment by geith.gm...@gmail.com on 22 Oct 2013 at 4:48

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Good idea

Original comment by almar.klein@gmail.com on 22 Oct 2013 at 9:09

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
I changed it accordingly. Could you do a last check?

Original comment by almar.klein@gmail.com on 25 Oct 2013 at 7:25

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by almar.klein@gmail.com on 26 Oct 2013 at 12:10