matplotlib-devel Mailing List for matplotlib

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> Hi John, Thanks for your reply - and the patch! I am about
    Jeremy> to check in an updated backend_wx which basically contains
    Jeremy> your changes, with one difference: I have refactored the
    Jeremy> code:

    Jeremy>         drawDC=wxClientDC(self) drawDC.BeginDrawing()
    Jeremy> drawDC.Clear() drawDC.DrawBitmap(self.bitmap, 0, 0)
    Jeremy> drawDC.EndDrawing()

Excellent, I was going to suggest the same.

I have rewritten the interactive interface so that you can call

import matplotlib
matplotlib.use('WX')
matplotlib.interactive(True)

(and I've removed the ShowOn abomination)

Perhaps you should just send me the latest version of you code in case
the mirror lags behind as usual and I'll then apply my patch to the
wx_backend for the new interface, and commit.

JDH

Hi John,

Thanks for your reply - and the patch! I am about to check in an updated 
backend_wx which basically contains your changes, with one difference: I have 
refactored the code:

        drawDC=wxClientDC(self)
        drawDC.BeginDrawing()
        drawDC.Clear()
        drawDC.DrawBitmap(self.bitmap, 0, 0)
        drawDC.EndDrawing()        

into a new function in FigureWX: gui_repaint(). I have done this for several 
reasons, but mainly because the same code appears in several places 
(FigureWX._onSize() as well as draw_if_interactive(), and it turns out to be 
needed for the Wx variant of interactive_demo (which I am also about to check 
in)).

I have also made a change so that if _DEBUG is set to a value less than 5 
(i.e. you are interested in debugging), the system exception hook is replaced 
with one which performs a traceback and enters pdb. This seems to work 
correctly for me on Linux, and I'll verify Win32 when I get back to work next 
week. It's a bit of an ugly hack, and I may rethink it later, but it's very 
handy for now, and doesn't intrude when not needed.

On Monday 29 December 2003 4:15 pm, John Hunter wrote:
> >>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:
>
>     Jeremy> A few questions for John Hunter: I think I need to do
>     Jeremy> something like the following: - show() must now
>     Jeremy> instantiate any figures already defined and enter the the
>     Jeremy> main event loop. ShowOn needs to keep track of this.  - I
>     Jeremy> need to keep track of the number of figures
>     Jeremy> instantiated. I assume that Gcf.destroy() does this.  - I
>     Jeremy> need to ensure that I do not exit when the last figure is
>     Jeremy> destroyed, and therefore need to manage that I may need to
>     Jeremy> create a new figure manager if there is none.
>
> Hi Jeremy,
>
> I think we should consider redoing this whole segment of the code from
> the ground up to make for a cleaner / cross GUI implementation.  It
> may be that Pearu Peteson <pe...@ce...> gui_thread code is the
> way to go for this since that is what is was designed to do (enable
> interactive control of WX plots (chaco) from the shell).  He has
> indicated a willingness to port it to pygtk provided we're willing to
> help test his code with the WX and GTK matplotlib backends.  However,
> this would create a scipy dependency...

I followed the thread form Pearu a few weeks back, although have not gotten 
around to trying the gui_thread code. I think there is something similar in 
the Python Cookbook for PyGtk (chapter 9.12), which might assist in doing a 
Gtk port.

I'm not keen on adding a dependency on scipy, but perhaps Pearu would consider 
making gui_thread its own module (or allowing us to do so). Checking back 
over the mail you sent to me, there are only three files involved. One of the 
things which drew me to working on Matplotlib was the small set of 
dependencies, and it would be a shame to loose this.

I'm very willing to play with the code he has with the Wx backend - I doubt 
that it will require much work on my behalf.

[snip]

> I don't think the current architecture for show, draw_if_interactive,
> ShowOn etc, is very elegant or easily understandable, and would be
> happy to refactor it for the next release.  Ideally we could handle
> these two cases across backends
>
>   1) defer all drawing until a call to show, which draws and realizes
>      all pending figures.  This should not hang the script, ie,
>      further drawing commands should be possible.

You'll notice in the code that I checked in that I have been playing with this 
in the backend_wx code. While it is possible to exit the mainloop, it seems 
that it is not possible to re-enter. It may be that I can do something akin 
to the Python Cookbook recepie I mentioned above for wx - it doesn't look too 
hard.

I have attached the code from the book example below, if you're interested.

>   2) do drawing with each matplotlib.matlab command for interactive
>      mode (current implementation in backend_gtk with ShowOn.set(1) at
>      start of script)

As you noteed, this now works with your fix.

> For the most part, I think we have this with the GTK backend, but it
> may be necessary to refactor in order to get something that works with
> both.  I'll think it over and take a look at the WX code to see if I
> get any ideas how to proceed.
>
> In the meantime, we should also see if we can get matplotlib to work
> with gui_thread -- I'll take a look at this too.
>
> JDH

Thanks again for the fix

Jeremy

====== interactive_gtk.py =====

import __builtin__, __main__
import codeop, keyword, gtk, os, re, readline, threading, traceback, signal, 
sys

def walk_class(klass):
    list = []
    for item in dir(klass):
        if item[0] != "_":
            list.append(item)

    for base in klass.__bases__:
        for item in walk_class(base):
            if item not in list: list.append(item)

    return list

class Completer:
    def __init__(self, lokals):
        self.locals = lokals
        self.completions = keyword.kwlist + \
                            __builtins__.__dict__.keys() + \
                            __main__.__dict__.keys()

    def complete(self, text, state):
        if state == 0:
            if "." in text:
                self.matches = self.attr_matches(text)
            else:
                self.matches = self.global_matches(text)
        try:
            return self.matches[state]
        except IndexError:
            return None

    def update(self, locs):
        self.locals = locs

        for key in self.locals.keys():
            if not key in self.completions:
                self.completions.append(key)

    def global_matches(self, text):
        matches = []
        n = len(text)
        for word in self.completions:
            if word[:n] == text:
                matches.append(word)
        return matches

    def attr_matches(self, text):
        m = re.match(r"(\w+(\.\w+)*)\.(\w*)", text)
        if not m:
            return
        expr, attr = m.group(1, 3)

        obj = eval(expr, self.locals)
        if str(obj)[1:4] == "gtk":
            words = walk_class(obj.__class__)
        else:
            words = dir(eval(expr, self.locals))

        matches = []
        n = len(attr)
        for word in words:
            if word[:n] == attr:
                matches.append("%s.%s" % (expr, word))
        return matches

class GtkInterpreter(threading.Thread):
    """ Run a GTK mainloop() in a separate thread. Python commands can be 
passed to the
    thread, where they will be executed. This is implemented by periodically 
checking for
    passed code using a GTK timeout callback. """
    TIMEOUT = 100 # interval in milliseconds between timeouts

    def __init__(self):
        threading.Thread.__init__ (self)
        self.ready = threading.Condition ()
        self.globs = globals ()
        self.locs = locals ()
        self._kill = 0
        self.cmd = ''       # current code block
        self.new_cmd = None # waiting line of code, or None if none waiting

        self.completer = Completer(self.locs)
        readline.set_completer(self.completer.complete)
        readline.parse_and_bind('tab: complete')

    def run(self):
        gtk.timeout_add(self.TIMEOUT, self.code_exec)
        gtk.mainloop()

    def code_exec(self):
        """ Execute waiting code. Called every timeout period. """
        self.ready.acquire()
        if self._kill: gtk.mainquit()
        if self.new_cmd != None:
            self.ready.notify()
            self.cmd = self.cmd + self.new_cmd
            self.new_cmd = None
            try:
                code = codeop.compile_command(self.cmd[:-1])
                if code:
                    self.cmd = ''
                    exec code, self.globs, self.locs
                    self.completer.update(self.locs)
            except:
                traceback.print_exc()
                self.cmd = ''

        self.ready.release()
        return 1

    def feed(self, code):
        """ Feed a line of code to the thread. This function will block until 
the code is
        checked by the GTK thread. Returns true if the thread has executed the 
code.
        Returns false if deferring execution until complete block is 
available. """
        if code[-1:]!='\n': code = code +'\n' # raw_input strips newline
        self.completer.update(self.locs)
        self.ready.acquire()
        self.new_cmd = code
        self.ready.wait()  # Wait until processed in timeout interval
        self.ready.release()

        return not self.cmd

    def kill(self):
        """ Kill the thread, returning when it has been shut down. """
        self.ready.acquire()
        self._kill=1
        self.ready.release()
        self.join()

# Read user input in a loop and send each line to the interpreter thread

def signal_handler(*args):
    print "SIGNAL:", args
    sys.exit()

if __name__=="__main__":
    signal.signal(signal.SIGINT, signal_handler)
    signal.signal(signal.SIGSEGV, signal_handler)

    prompt = '>>> '
    interpreter = GtkInterpreter()
    interpreter.start()
    interpreter.feed("from gtk import *")
    interpreter.feed("sys.path.append('.')")
    if len (sys.argv) > 1:
        for file in open(sys.argv[1]).readlines():
            interpreter.feed(file)
    print 'Interactive GTK Shell'

    try:
        while 1:
            command = raw_input(prompt) + '\n' # raw_input strips newlines
            prompt = interpreter.feed(command) and '>>> ' or '... '
    except (EOFError, KeyboardInterrupt): pass

    interpreter.kill()
    print

I find that when an assertion fails or another exception is raised in
the wx backend, python just exits silently without printing the
traceback or the exception that occurred.  This makes it difficult to
work with the wx backend.

Is there a setting so that I can get the traceback, or another
preferred method?

Thanks,
John Hunter

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:


    Jeremy> I can say that in the original design, the intention was
    Jeremy> that show() would be the last line of any script. I know
    Jeremy> that John (author of virtually everything in Matplotlib
    Jeremy> except backend_wx) has recently made some changes to allow
    Jeremy> show() to be called more than once.

    Jeremy> Unfortunately, the code needed to do thisis quite specific
    Jeremy> to each GUI library, and I cannot simply port what has
    Jeremy> been done for GTK (I've just tried something very close to
    Jeremy> the GTK implementation, and it doesn't work).

    Jeremy> A few questions for John Hunter: I think I need to do
    Jeremy> something like the following: - show() must now
    Jeremy> instantiate any figures already defined and enter the the
    Jeremy> main event loop. ShowOn needs to keep track of this.  - I
    Jeremy> need to keep track of the number of figures
    Jeremy> instantiated. I assume that Gcf.destroy() does this.  - I
    Jeremy> need to ensure that I do not exit when the last figure is
    Jeremy> destroyed, and therefore need to manage that I may need to
    Jeremy> create a new figure manager if there is none.

Hi Jeremy,

I think we should consider redoing this whole segment of the code from
the ground up to make for a cleaner / cross GUI implementation.  It
may be that Pearu Peteson <pe...@ce...> gui_thread code is the
way to go for this since that is what is was designed to do (enable
interactive control of WX plots (chaco) from the shell).  He has
indicated a willingness to port it to pygtk provided we're willing to
help test his code with the WX and GTK matplotlib backends.  However,
this would create a scipy dependency...

But let me give a little overview of why the code is currently the way
it is.  When the use calls 'show' it realizes all the figures and sets

  self.show = on

This is a critical part, because the function draw_if_interactive
(which is called by every matplotlib.matlab command) only draws if
this variable is set

def draw_if_interactive():
    if ShowOn().get():
        figManager =  Gcf.get_active()
        if figManager is not None:
            fig = figManager.figure
            fig.draw()
            fig.queue_draw()

The point I want to emphasize is that the primary reason there is a
difference between interactive and batch mode is for efficiency.  In
interactive mode, the entire figure must be redrawn with each command
(eg, setting an xlabel, changing a ticklabel property, etc...).  This
can get quite expensive when you want to set a lot of properties.
Thus the default 'batch mode' defers all the drawing operations until
the end for efficiency, and just makes one draw.

I don't think the current architecture for show, draw_if_interactive,
ShowOn etc, is very elegant or easily understandable, and would be
happy to refactor it for the next release.  Ideally we could handle
these two cases across backends

  1) defer all drawing until a call to show, which draws and realizes
     all pending figures.  This should not hang the script, ie,
     further drawing commands should be possible.
        
  2) do drawing with each matplotlib.matlab command for interactive
     mode (current implementation in backend_gtk with ShowOn.set(1) at
     start of script)

For the most part, I think we have this with the GTK backend, but it
may be necessary to refactor in order to get something that works with
both.  I'll think it over and take a look at the WX code to see if I
get any ideas how to proceed.

In the meantime, we should also see if we can get matplotlib to work
with gui_thread -- I'll take a look at this too.

JDH

Hi John,

jdh...@ac... wrote:
> 
> I'd like to do the 0.40 release early next week to the wxpython,
> python-list, etc, communities.  Do you think it's time?

I'm reasonably happy with the backend quality for now, and I think the only way we'll start to really squash the bugs is to get more people using matplotlib.

Yes, I think it's time.

> The only significant bug I'm aware of, and it's an important one, is
> the problem with vertical rendering of text in the wxpython with GTK2
> backend.  Unfortunately, since it appears to be a known bug, I'm not
> sure what we can do about it, except perhaps remind Robin Dunn and the
> other wx developers about the problem.
> 
> Your thoughts?

The best approach is probably as you suggest. If we release, perhaps we can find a friendly developer of wxPython with GTK2 who can perhaps help us. I'd agree that it's a significant issue, and I guess that most newer Linux distributions have probably given up on GTK 1.2. I may reconsider whether to try to do a wxPython build linked against GTK2. Debian has a 'fakeroot' utility, which may help me.

Regards

Jeremy

I'd like to do the 0.40 release early next week to the wxpython,
python-list, etc, communities.  Do you think it's time?

The only significant bug I'm aware of, and it's an important one, is
the problem with vertical rendering of text in the wxpython with GTK2
backend.  Unfortunately, since it appears to be a known bug, I'm not
sure what we can do about it, except perhaps remind Robin Dunn and the
other wx developers about the problem.

Your thoughts?
JDH

>>>>> "Zachary" == Zachary Pincus <zp...@st...> writes:

    Zachary> Hello - I just posted a few bugs (and patches to fix
    Zachary> them) to the sourceforge bugtracker page before I
    Zachary> realized that the email list is preferred.

More people see the list I think, but the SF mirror for the dev list
is generally woefully out of date, so it's a tossup.

    Zachary> Short story: I found and (hopefully) fixed a problem with
    Zachary> pcolor on non-square arrays, a startup error in the
    Zachary> interactive.py shell, and a problem with repeated output
    Zachary> when saving postscript backend figures. The details of
    Zachary> the bugs and patches are copied below.

Thanks for the detailed information and patches!

    Zachary> This happens because the shape of the X and Y arrays (the
    Zachary> output of a meshgrid call on line 1782) have the wrong
    Zachary> shape. In particular, the shape is backward.  e.g. if
    Zachary> C.shape = (x,y), then X.shape = Y.shape = (y, x).

The behavior of meshgrid certainly is a bit counter-intuitive.  Eg, in
matlab

    >> x = [1:7];
    >> y = [1:5];
    >> [X,Y] = meshgrid(x,y);
    >> Z = rand(length(x), length(y));
    >> pcolor(X,Y,Z);
    ??? Error using ==> surface
    Matrix dimensions must agree.

matplotlib fails in the same way.  I've updated the docs in meshgrid,
pcolor and fixed the meshgrid call in the case of pcolor(Z) for
nonsquare Z.

I added the following to the pcolor docs - let me know if you agree
with this.

"""
    Note, the behavior of meshgrid in matlab is a bit
    counterintuitive for x and y arrays.  For example,

      x = arange(7)
      y = arange(5)
      X, Y = meshgrid(x,y)

      Z = rand( len(x), len(y))
      pcolor(X, Y, Z)

    will fail in matlab and matplotlib.  You will probably be
    happy with

      pcolor(X, Y, transpose(Z))

    Likewise, for nonsquare Z,

      pcolor(transpose(Z))

    will make the x and y axes in the plot agree with the numrows
    and numcols of Z
"""

    Zachary> Patch: Change matplotlib/axes.py line 1782 from: X, Y =
    Zachary> meshgrid(range(numRows), range(numCols)) to: X, Y =
    Zachary> meshgrid(range(numCols), range(numRows))

Done

    Zachary> (*)
    Zachary> http://matplotlib.sourceforge.net/matplotlib.mlab.html#-meshgrid

Fixed doc bug.


    Zachary> Patch: Insert the command: interpreter.feed("from
    Zachary> matplotlib.backends.backend_gtk import ShowOn") somewhere
    Zachary> before line 206.

Fixed -- I don't know how this got removed.

    Zachary> Patch: Insert the following lines at the end of the
    Zachary> print_figure method of the FigurePS class in the file
    Zachary> matplotlib/ backends/backend_ps.py (line 189):
    Zachary> self._pswriter = StringIO()
    Zachary> self._pswriter.write(_psHeader)

Added a flush method, called by __init__ and after writing the figure.

Thanks again -- that was very helpful.

John Hunter

Hello -

I just posted a few bugs (and patches to fix them) to the sourceforge 
bugtracker page before I realized that the email list is preferred.

Short story: I found and (hopefully) fixed a problem with pcolor on 
non-square arrays, a startup error in the interactive.py shell, and a 
problem with repeated output when saving postscript backend figures. 
The details of the bugs and patches are copied below.

Zach Pincus


Here is the relevant information:
----------------------------------
pcolor(array) fails when array is not square, on version
0.40i of matplotlib.

Details:
A non-square array causes an indexError on line 1798 of
matplotlib/axes.py:
c = C[i,j]
because iteration has continued past the edge of the array.

This happens because the shape of the X and Y arrays (the
output of a meshgrid call on line 1782) have the wrong
shape. In particular, the shape is backward.
e.g. if C.shape = (x,y), then X.shape = Y.shape = (y, x).

Patch:
Change matplotlib/axes.py line 1782 from:
X, Y = meshgrid(range(numRows), range(numCols))
to:
X, Y = meshgrid(range(numCols), range(numRows))

Rationale:
Meshgrid(range(x), range(y)) returns arrays with
a shape of (y, x), which is a bit counterintuitive.
The documentation(*) bears this out. It is confusing
because the convention therein is that a Nx x Ny entry
array has Nx columns and Ny rows, while a (Nx, Ny)-
shaped array (in Matlab as well as Numeric) has Nx rows
and Ny columns. I don't know why the original meshgrid in
matlab worked this way, but it does.

(*) http://matplotlib.sourceforge.net/matplotlib.mlab.html#-meshgrid

----------------------------------

Problem: examples/interactive.py (version 0.40i) does not
start up properly.

Details: A NameError is raised on startup when the
command on line 206 fails:
interpreter.feed ("ShowOn().set(1)")
This is because ShowOn is not in the global namespace.

Not running ShowOn().set(1) breaks interactive mode
badly.

Patch:
Insert the command:
interpreter.feed("from matplotlib.backends.backend_gtk import ShowOn")
somewhere before line 206.

----------------------------------

Problem:
If savefig() is called more than once on a postscript backend
figure, extra copies of the figure will be appended to the
output.

Details:
Regardless of the file name that the figure is saved under,
each time savefig() is called, an additional copy of the figure
appears at the end of the postscript output. So if savefig() is
called four times, the output from that fourth call will be
four copies of that figure on a multipage postscript file.

Patch:
Insert the following lines at the end of the print_figure
method of the FigurePS class in the file matplotlib/
backends/backend_ps.py (line 189):
self._pswriter = StringIO()
self._pswriter.write(_psHeader)

Rationale:
The postscript backend is not clearing the pswriter
accumulator buffer between repeated calls to print_figure.
So after each call, another copy of the figure gets added to
the buffer and dumped to the output. The patch re-
initializes the pswriter buffer.

Note that the patch is sort of bad form because it duplicates
the pswriter initialization code from the __init__ method of
that class. So if the init method is changed, the patched
lines need to be changed too. Better would be to move the
pswriter initialization to a separate function and call that
from both the init and print_figure methods.

On Tuesday 02 December 2003 8:29 pm, Jeremy O'Donoghue wrote:
> I'm seeing a failure with one of my asserts, so I'll start there. Should
> have more info shortly.

I have just run through all of the regression tests, and with

assert self.Ok()

in GraphicsContextWx.__init__() removed, all works correctly on my Debian 
platform. 

My suspicion is that the problem is that wxGTK does not like to see calls to 
Ok() in derived constructors. Please let me know if this fixes the problem on 
your machine, John, as I now have no problems on the two platform available 
to me.

A few other notes:

- Save to TIFF does not work on my Linux box. wxGTK generates a 'not 
supported' error message.
- Text is not anti-aliased on my Linux box. I suspect that this is probably a 
GTK configuration issue on my box (other GTK 1.2 apps aren't anti-aliased 
either), but I'd love confirmation.
- Performance of double buffering is vastly better on wxGTK than on Win32. The 
performance under Linux is subjectively very similar to the old GDI-style 
version, but (as previously noted) much worse under Win32. I am not sure why 
this should be the case (my Linux box is much lower spec than the Win32 box, 
as well!)

Regards

Jeremy

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> At least on my platform, it looks as though commenting out
    Jeremy> the line assert self.Ok(), "wxMemoryDC not OK to use" in
    Jeremy> GraphicsContextWx.__init__() solves the problem. I am not
    Jeremy> at all sure why this should be the case.

    Jeremy> I'd be interested to know if this works for you too.

I commented it out (everywhere) and it ran fine.  Apparently it was
hanging ...

  Two quick observations - 

   - figtext renders a completely black screen
   - vertical text still broken 

Otherwise the figures look fantastic!

JDH

On Tuesday 02 December 2003 8:29 pm, Jeremy O'Donoghue wrote:
>
> I'm seeing a failure with one of my asserts, so I'll start there. Should
> have more info shortly.

At least on my platform, it looks as though commenting out the line
assert self.Ok(), "wxMemoryDC not OK to use"
in GraphicsContextWx.__init__() solves the problem. I am not at all sure
why this should be the case.

I'd be interested to know if this works for you too.

Just running through the regression suite on Linux to make sure there are no 
other oddities.

Regards

Jeremy

On Tuesday 02 December 2003 6:22 pm, John Hunter wrote:
> >>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:
>
>     Jeremy> I have attached the updated backend_wx.py. Obviously if
>     Jeremy> I've broken wxGTK I'll need to look into it as a matter of
>     Jeremy> urgency.
>
> Probably is a GTK2 thing.  Do you have access to a GTK2 machine to
> test?

Don't have access to a GTK2 version of wxPython...
But I've just diagnosed the same problem on my Linux box. Since the code 
worked this morning, I probably haven't broken much, but these wxMemoryDC 
calls really don't behave quite the same way on Windows and GTK.

I'm seeing a failure with one of my asserts, so I'll start there. Should have 
more info shortly.

Regards

Jeremy

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> I have attached the updated backend_wx.py. Obviously if
    Jeremy> I've broken wxGTK I'll need to look into it as a matter of
    Jeremy> urgency.

Probably is a GTK2 thing.  Do you have access to a GTK2 machine to
test?

    Jeremy> This sounds worryingly as though you do have the latest
    Jeremy> version (there was no file save dialog code at all until
    Jeremy> this morning).

Yep, same problem with the attached code.

    Jeremy> In particular, the behaviour of a wxMemoryDC (which is the
    Jeremy> context used to draw into the bitmap) seems quite
    Jeremy> different between the two platforms. The main bug I've had
    Jeremy> to deal with is that the bitmap can only be selected into
    Jeremy> a single wxMemoryDC at a time. This means that I have to
    Jeremy> take explicit care to ensure that whenever a
    Jeremy> GraphicsContextWx.new_gc() is called, I explicitly ensure
    Jeremy> that the bitmap is selected from the last wxMemoryDC.

I diagnosed why the print code doesn't save a file.  It hangs
indefinitely on the call to

  gc = self.drawable.new_gc()

    Jeremy> The other thing to look for is in the _onSize and _onPaint
    Jeremy> methods of FigureWx: the image from the bitmap is sent to
    Jeremy> the screen with a Blit() call. This seems to be necessary
    Jeremy> on Windows as the (simpler, but equivalent) DrawBitmap()
    Jeremy> call does not work properly.

Tried Blit versus DrawBitmap in both.  No help

    Jeremy> Where the printing is concerned, again, you could try
    Jeremy> uncommenting the 'self.bitmap.SaveFile()' line, which
    Jeremy> checks whether it is possible to save a 'known good'
    Jeremy> bitmap.

No help, due to the hang on new_gc

Any other ideas?

JDH

Hi John,

John Hunter said:
>
[snip]
>
> One minor glitch.  I just did an update to backend_wx Repository
> revision: 1.15.  When I launch a figure, eg
>
>  > python subplot_demo.py -dWX
>
> The window comes up and looks properly placed and sized, but no image
> appears in the figure window.  I have the window, the toolbar etc,
> only no axes, no plot.  Hmmm....  RHL9, GTK2, wxPythonSrc-2.4.2.4.

I hope not. I haven't yet fully regression tested on Debian (a job for
tonight), but I'd be surprised as all seemed OK in Linuxland this morning
(barring a few glitches in the figure saving code).

I have attached the updated backend_wx.py. Obviously if I've broken wxGTK
I'll need to look into it as a matter of urgency.

> When I click on the save dialog, it pops up, prompts me for a
> filename, and then does noting -- no file is created.
> Perhaps I have the older version of backend_wx (sometimes the CVS
> mirrors are behind).  If so, please send me the attachment.

This sounds worryingly as though you do have the latest version (there wa=
s
no file save dialog code at all until this morning).

> Otherwise, if you have any insights, please let me know.

I have noticed that the behaviour of wxPython when using bitmaps is
slightly different between Windows and GTK. My own machine has wxPython
linked against GTK 1.2 (I think) so there may be some differences there.

In particular, the behaviour of a wxMemoryDC (which is the context used t=
o
draw into the bitmap) seems quite different between the two platforms. Th=
e
main bug I've had to deal with is that the bitmap can only be selected
into a single wxMemoryDC at a time. This means that I have to take
explicit care to ensure that whenever a GraphicsContextWx.new_gc() is
called, I explicitly ensure that the bitmap is selected from the last
wxMemoryDC.

The other thing to look for is in the _onSize and _onPaint methods of
FigureWx: the image from the bitmap is sent to the screen with a Blit()
call. This seems to be necessary on Windows as the (simpler, but
equivalent) DrawBitmap() call does not work properly.

You may (as a matter of interest) want to try going to around line 712,
where, just under the call to drawDC.Blit() there is a call to
drawDC.DrawBitmap() which is commented out. Comment the call to Blit() an=
d
uncomment DrawBitmap() (they are equivalent) and see if the figure appear=
s
on screen.

Where the printing is concerned, again, you could try uncommenting the
'self.bitmap.SaveFile()' line, which checks whether it is possible to sav=
e
a 'known good' bitmap.

These may give some insights if there is unexpected platform-specific
behaviour. You'll notice that I have put quite a few 'assert' statements
in the low-level code to try to trap this sort of thing.

>     Jeremy> I should note that performance of the double-buffered
>     Jeremy> drawing backend is not as good as the previous GDI version
>     Jeremy> (at least on Windows), although animated drawing will be
>     Jeremy> flicker-free. I would be interested to hear opinions on
>     Jeremy> whether people prefer double buffered drawing or GDI, and
>     Jeremy> whether it makes sense to support both (as an option when
>     Jeremy> creating a figure, perhaps).
>
> If it's not hard to support both, why not.  I prefer flicker free
> navigation and animation over performance, and in most cases find the
> performance of matplotlib acceptable (pcolor being a notable
> exception).  But I have a fast machine.

It's not too hard to support both - I'd have to go and rescue some of the
old code, and rethink (again) how to support wxDC classes in
GraphicsContextWx (as I'd have to support three different types)

>     Jeremy> John, is it worth activiating the Sourceforge bug tracker
>     Jeremy> after 0.4 release?
>
> I think it is active.  There have been 4 bug reports and 1 patch there
> already.  I'm willing to go either way here.  I find it easier to
> check the mail list than the SF site, but I can train myself otherwise
> if you think it's worthwhile to do so.

I'm happy with either, although users may prefer the bug list - especiall=
y
given the lamentable performance of SF in archiving matplotlib-devel,
which make it difficult for the casual user to browse the list of known
bugs before reporting new ones.

Let me know how you get on. I'll look hard at things on my Linux box late=
r.

Regards

Jeremy

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> I have just committed a significant update to backend_wx.
    Jeremy> The intention is that this will be the basis of the
    Jeremy> backend_wx code in release 0.40 of Matplotlib. It contains
    Jeremy> numerous small fixes, but the highlights are:

Hi Jeremy, 

This sounds great.  It looks like everything is about ready to go.

One minor glitch.  I just did an update to backend_wx Repository
revision: 1.15.  When I launch a figure, eg

 > python subplot_demo.py -dWX

The window comes up and looks properly placed and sized, but no image
appears in the figure window.  I have the window, the toolbar etc,
only no axes, no plot.  Hmmm....  RHL9, GTK2, wxPythonSrc-2.4.2.4.

When I click on the save dialog, it pops up, prompts me for a
filename, and then does noting -- no file is created.

Perhaps I have the older version of backend_wx (sometimes the CVS
mirrors are behind).  If so, please send me the attachment.

Otherwise, if you have any insights, please let me know.

    Jeremy> I should note that performance of the double-buffered
    Jeremy> drawing backend is not as good as the previous GDI version
    Jeremy> (at least on Windows), although animated drawing will be
    Jeremy> flicker-free. I would be interested to hear opinions on
    Jeremy> whether people prefer double buffered drawing or GDI, and
    Jeremy> whether it makes sense to support both (as an option when
    Jeremy> creating a figure, perhaps).

If it's not hard to support both, why not.  I prefer flicker free
navigation and animation over performance, and in most cases find the
performance of matplotlib acceptable (pcolor being a notable
exception).  But I have a fast machine.

    Jeremy> Known bugs are:

    Jeremy>  - Mousewheel (on Windows) only works after menu button
    Jeremy> has been pressed at least once. I do not plan to fix this
    Jeremy> since John is planning to rewrite the navigation code for
    Jeremy> backend_gtk to work more like matlab.

    Jeremy>  - Mousewheel on Linux (wxGTK linked against GTK 1.2) does
    Jeremy> not work at all Suspect that this is a GTK 1.2 issue, but
    Jeremy> in any event, it's something else I don't plan to fix.

I'm not too worried about mouse wheel stuff for the first release,
especially with changes to the navigation bar approaching.

    Jeremy> John, is it worth activiating the Sourceforge bug tracker
    Jeremy> after 0.4 release?

I think it is active.  There have been 4 bug reports and 1 patch there
already.  I'm willing to go either way here.  I find it easier to
check the mail list than the SF site, but I can train myself otherwise
if you think it's worthwhile to do so.

JDH

I have just committed a significant update to backend_wx.

The intention is that this will be the basis of the backend_wx code in
release 0.40 of Matplotlib. It contains numerous small fixes, but the
highlights are:

 - Implemented double-buffered drawing
 - GraphicsContextWx now inherits from wxMemoryDC (consequence of double
   buffered drawing)
 - Implemented save to JPEG, Windows BMP, PNG, TIF, PCX, XPM formats
 - Incorrect initial figure window placement on some Unix platforms
 - Mouse wheel (subject to known bug) works in Windows
 - Toolbar button presses cause multiple events on Windows platform
 - Width of figure frame now correct in Windows
 - Figures now respond correctly to resize events
 - Sets self._reset =3D False in AxisTextWx.__set_font() as per info
   from JDH in axes.py
 - figtext.py now works correctly - text attributes retained correctly

I should note that performance of the double-buffered drawing backend is
not as good as the previous GDI version (at least on Windows), although
animated drawing will be flicker-free. I would be interested to hear
opinions on whether people prefer double buffered drawing or GDI, and
whether it makes sense to support both (as an option when creating a
figure, perhaps).

Known bugs are:

 - Mousewheel (on Windows) only works after menu button has been pressed
   at least once. I do not plan to fix this since John is planning to
   rewrite the navigation code for backend_gtk to work more like matlab.

 - Mousewheel on Linux (wxGTK linked against GTK 1.2) does not work at al=
l
   Suspect that this is a GTK 1.2 issue, but in any event, it's something
   else I don't plan to fix.

 - Vertical text renders horizontally if you use a non TrueType font
   on Windows. This is a known wxPython issue. Work-around is to ensure
   that you use a TrueType font.

 - Pcolor demo puts chart slightly outside bounding box (approx 1-2 pixel=
s
   to the bottom left). This issue also exists in backend_gtk (the code
   in this area is substantially the same for both backends)

 - Outputting to bitmap more than 300dpi results in some text being
   incorrectly scaled. Seems to be a wxPython bug on Windows for font
   point sizes > 60, as font size is correctly calculated. Workaround
   is to use DPI <=3D 300. I only found the problem for 360DPI plots.

With the exception of the known bugs above, please report any other issue=
s
via the matplotlib-devel mailing list. I will try to fix them, but in the
meantime, I'm keen to get a Debian package for 0.4 put together.

John, is it worth activiating the Sourceforge bug tracker after 0.4 relea=
se?

Regards

Jeremy

Hi John,

I thought I'd better keep you updated on backend_wx progress, as it's bee=
n
a while since I've checked everything in.

Main reason is that I've been working on the 'savefig' option, which
prompted a decision to move the entire backens, as you suggested, to use
double-buffered drawing.

This has proven slightly more complicated than I at first thought, and I
haven't checked any code in as backend_wx is in a rather worse state than
the current CVS version. This is being dealt with rapidly, however, and
things are now almost back to where they were previously.

The good news is that I've fixed most of the known bugs, and much of the
backend code is now cleaner. I'm targetting getting something into CVS
over the next couple of days, provided that I can get to a point where I'=
m
happy with it on Win32 and Linux platforms (it seems that double bufferin=
g
behaves rather differently on the two platforms, and there have been quit=
e
a few subtlties I've had to work out).

One bug which I don't think will be fixed before 0.40 is mousewheel on
wxGTK - I think this simply doesn't work properly on the version of wxGTK
installed on my Linux box. However, operation of the buttons themselves i=
s
fine.

Anyway, hopefully you should see something in the CVS pretty shortly.

Regards

Jeremy