On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell <brenb...@brenbarn.net>wrote:
> [Accidentally sent this reply privately the first time, natch.]
>
> On 2011-05-11 04:29, Jae-Joon Lee wrote:
> > > On Wed, May 11, 2011 at 5:03 PM, Daniel Mader
> > > <danielstefanma...@googlemail.com> wrote:
> >> >> Hi Jae-Loon,
> >> >>
> >> >> thanks for your comments! Of course I do agree that a figure
> layout
> >> >> should not change in interactive mode. However, I don't see
> why this
> >> >> should happen upon a panning action. A different case is when the
> >> >> label or title font sizes are changed, but I was assuming this is
> >> >> adjusted prior to the creation of the figure.
> >> >>
> > >
> > > Since you said the current design is broken, I thought you want
> things
> > > adjusted *whenever* a figure is updated.
> > >
> > > So, I guess what you want is some functionality like what Tony's
> script does?
> > > One of the reason that I was not very inclined to Tony's approach is
> > > that it only works for subplots (and I guess it only works with
> > > subplots with pure n x m grid. Correct me if I'm wrong). But maybe it
> > > is better than nothing. I'll consider how things can be improved.
>
> One thing I've always wondered: is it fundamentally impossible to
> change the fact that, in matplotlib, you cannot know how big a drawn
> object will be until you actually draw it? When I was doing some
> animation stuff a while back this caused me a lot of headache, for the
> reasons Tony Yu mentioned: it means you have to draw everything
> multiple times. It would really help if it were possible to specify
> objects' parameters and get their sizes without drawing them.
>
> -- Brendan Barnwell
> "Do not follow where the path may lead. Go, instead, where there is no
> path, and leave a trail." --author unknown
>
>
Most things, we do know the sizes of. It is my understanding that it is the
text objects that is the unknown. If this could be solved, then a layout
engine would be much more feasible. The problem is that even LaTeX has to
re-render things multiple times to get this right for an arbitrary font. If
we were to restrict ourselves to particular fonts and package those fonts
with matplotlib, then we could have an internal table of size information
for each glyph and compute it on the fly and lay everything out right. But,
that would cause us to give up significant benefits for another benefit.
I think the pain of the bootstrapping/re-rendering approach could be reduced
significantly if we could get various aspects of matplotlib figure building
to be faster. Last time I checked, there is significant amount of
processing time spent in calculating the ticks for the axes. Maybe if we
focus some efforts in improving the efficiency of certain parts of
matplotlib, maybe we could introduce a convenience function like the one
earlier in this thread that some users can choose to use with only a slight
penalty in speed. I personally would not want to make it default, but
certainly would consider highly advertising such a function.
Just my two cents,
Ben Root
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
