[Scipy-chaco] RE: [SciPy-user] FW: anti-grain

[David Ascher]

eric jones wrote:

> ???  I don't quite get this.  We have to know the sizes of the axis
> labels (both titles and numbers) to trim off enough real estate around a
> plot so that the numbers don't overlap onto the graph (y labels) or onto
> each other (x labels).  I'm not sure how you would do this without
> precalculating the actual screen size of the text.

You're right.  I didn't realize the sophistication in your algorithms (I should 
have, I've admired the tick marks and labeling choices).

> It would be better not to have the reportlab dependency if we don't
> loose any capabilities, so if the backend is trivial (nearly identical
> to the PS one I guess?), I'm for removing the dependency.

Ok, I'll try and do that later this week.

> I'm betting OpenGL will win -- or if it doesn't now, it will in the
> future.  Unless there is a compelling reason to get rid of it at some
> point, keeping an OpenGL backend seems like a good idea.  There are only
> a few features that will be problematic with it (and probably won't be
> supported).  These include "join mitering" and "line end caps."  

I've never needed those in display code -- only in printouts.  PIL will never 
support that either, and I don't care =).

> The
> other thing I'm a little worried about is thick lines.  I think some
> OpenGL implementations don't support lines thicker than 10 points.
> Beyond that, you have to draw a polygon.  This will lead to silly
> if/then code.  There are probably other things, but Dave Morrill, has
> gotten it all 90% there.

There are other weirdnesses, such as the fact that OpenGL "points" are in screen 
pixels, not in viewspace coordinates.  But since Kiva doesn't support points 
yet, you haven't noticed it =).

[..docs...]

> I promise that this will be remedied, but I won't promise when. :-)

I'll produce a quick writeup of how to do a backend like the ones I did -- 
someone else can write the "interactive" part.

What I'm most in need of isn't Kiva information -- that code is fairly 
straightforward.  It's the Chaco class hierarchy and fancy 'delegate' handling 
which I'd love to learn more about.

Ooh.  I just figured out how to do compound plots -- there's a minor bug in 
plot_container.py:NestedContainers._add_item() -- it shouldn't fail if there's 
no "window" attribute.  With a try/except around that access, I get compound 
plots w/o having to invoke any of the GUI stuff.  Yeehah!

[Aside: why do some lines in .co files have the format "foo = bar" while others 
have "foo: bar"?]

> Wait a second... Something must be wrong with the email transmission
> here.  I'm missing the file where you defined all the javascript code to
> support interaction with the plot.:-)

Until I get marker support code in Kiva, there's not much point to doing that. 
I'm don't see SVG as the base for a full-fledged interactive UI (although that 
would be cool in a sick kind of way) -- but I do want to support some "data 
mining operations" -- click on a marker hits another web page that gives you 
more details about that data point, etc.  That will happen by adding metadata to 
individual data points (aka markers).

--david