The recent zorder-related changes broke the some of the rasterization
feature, and I just committed a fix. In doing so, I replaced
dsu.sort(key=lambda x: x[0])
to
dsu.sort(key=itemgetter(0))
which I think is slightly faster (although speed is not much of concern here).
Jae-Joon Lee wrote:
The recent zorder-related changes broke the some of the rasterization
feature, and I just committed a fix.
Thanks Jae-Joon.
Is it easy to turn this into a test so that it never unintentionally
crops up again?
Thanks,
Andrew
Jae-Joon Lee wrote:
The recent zorder-related changes broke the some of the rasterization
feature, and I just committed a fix. In doing so, I replaced
dsu.sort(key=lambda x: x[0])
to
dsu.sort(key=itemgetter(0))
which I think is slightly faster (although speed is not
All,
I have been looking at some of the recent z-order changes and have found an
issue that breaks previous behavior. Previously when
items were added to a Figure or an Axes with the same z-order value, they were
rendered in order of when they were added, so that
the first one added is
James Evans wrote:
All,
I have been looking at some of the recent z-order changes and have found an
issue that breaks previous behavior. Previously when
items were added to a Figure or an Axes with the same z-order value, they
were rendered in order of when they were added, so that
the
James Evans wrote:
All,
I have been looking at some of the recent z-order changes and have found an
issue that breaks previous behavior. Previously when
items were added to a Figure or an Axes with the same z-order value, they
were rendered in order of when they were added, so that
the
On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing efir...@hawaii.edu wrote:
This is easy to fix by using the key kwarg (added in python 2.4) of the
sort method, because python uses a stable sort. It looks like it only
needs to be fixed in Axes.draw, because Figure.draw has never paid any
attention
