I'd be glad, if a lot of people could post their experiences with the first alpha release together with requests for new features.
Thanks a lot
1) my personal interest
I'm interested in making graphs in java, in fact I need it in my
work, and once I've already used some library for our statistical
package: I went through I-net, but I hadn't found nothing exciting.
There wasn't a lot of time, so I grabbed some code of old library
(in AWT) and adjusted it for our needs. Unfortunatelly the Object model
was old-fashioned, so in this time I'm looking for something better or/and
think about writing new one. JOpenLibrary seems to have solid roots to
expand and tune to be mature and flexible system.
I'm ready to cooperate, bring some experiences and opinions from real users
and write some parts of java open charting library - if you want and if my
visions are not too far from yours:
2) my visions about library (what it should know)
DataSet types - points lines - straight - curves - pointed line
- splines - several types of approximation and interpolation (Catmul-Rom, Bezier, ...)
bars - more than one dataSet (also in 3D)
pie - also in 3D
User interaction - zooming, data selection, graph settings should be available via option panel -> changing color, line styles, legends...
Graphics - vertical, horizontal, (general angle) text marks assigned to column/bars, points, - axes adjustable legends placed on independent movable pane adjustable - title placed on independent movable pane antialiasing
- good look is very, very important
I've passed through code and documentation of the library and here are
some technical notes:
Cannot be said that all things works properly, for example documentation from downloaded zip
(a lot of broken links, two packages (de.cut5.charting.model... - de.progra.charting.model...),
on the other side code is well documented and readable.
Absoute paths in tests for example "M:\test.png", backup files *~ increase size of package
>>ChartDataModel::public int getDataSetLength(int set)
>>Returns the length of a certain dataset. Note that for proper rendering all datasets should have an equal length.
>>The model is basically resembling a Swing table model. Furthermore, in the implementation
>>it needs to be defined whether the datasets are organized in rows or in columns,
DataSets must be allowed to have different sizes.
Mabye table model will not be sufficiently flexible :-(
I'm not sure about the thing how closely are tight issues like python and encoders
with library. I think library core should work without these extensions.
I hope, my mail is not too critic. I believe that jopenchart started well and may be
very usefull for hundreds of developers.
Have a nice day
your mail is definitely not too critic. Any criticism is very welcome, especially if it's so detailed. Our visions about what the library should do are pretty close, they're almost congruent. I will create a new file release today fixing the mentioned problems and I will be splitting it up into a binary, source and doc release.
I'd be very glad if you would join the team (it's not even a team yet, it's just me ;-) so if you like, I'll put you on the developer list.
I've already thought about some of the things you mentioned, especially the DataSet thing. Of course, a TableModel is not flexible enough. So far I just refrained from implementing it because I did it incrementally. A TableModel approach works for most spreadsheet like things. The ChartDataModel and DataSet classes basically have everything they need to allow different sized DataSets. What's lacking is basically a constructor in the DataModel class.
I think though, that differently sized DataSets are only of use for numerical DataSets and therefore, they only need to be implemented in the DefaultChartDataModel and in the line and plot style renderers. I cannot imagine a use of them in bar charts or pie charts, maybe you can ;-)
I must admit though, that so far I didn't think thoroughly about the user interaction stuff like zooming and panning etc. I'd like that functionality though. It will need a little parameterizing of the CoordSystem, ChartDataModel and the renderer classes to do zooming. Rotating 3D charts wouldn't be much of a problem since you could include a multiplication matrix for the 3D coordinates in the PointToPixelTranslator once it can also translate 3D coordinates.
About the extension library. I don't think the Python stuff is very integrated. It's just one class hanging around that needs it. For the encoding stuff you're certainly right, that's not so nice the way it is.
well, I'm getting new version now and going to familiarize with library more precisely. I'm glad we share the same goals.
I'd be glad to join the team; my time is limited due to my work, so please rather wait with my adding to developer list till I post some usefull contribution. I hope it will be soon.
I also cannot imagine using of differently sized DataSets in pie or bar charts.
I've continued in testing and here are some notes:
COMPILE ERRORS (jdk1.3):
de\progra\charting\test\PythonTest.java:69: incompatible types
found : double
pymodel = (double)interp.get("model", double.class);
de\progra\charting\test\PythonTest.java:70: incompatible types
found : double
pycolumns = (double)interp.get("columns", double.class);
It is possible to create LineChartRenderer with constructor
LineChartRenderer(ChartDataModel model, RowColorModel rcm) and
then collaps on missing PointToPixelTranslator
Test is probably suitable for older version of CoordSystem class
When testing GraphFrame.java, after closing
main frame, application went on. Mabye function initComponents() isn't called.
I don't know which building tool do you use, but I suppose it will be nice to write some Makefile for quicker start. For example:
CORE_CLASSES = \
EVENT_CLASSES = \
MODEL_CLASSES = \
RENDERER_CLASSES = \
SERVLET_CLASSES = \
SWING_CLASSES = \
TEST_CLASSES = \
#not used $(TEST_CLASSES) $(SERVLET_CLASSES)
all: $(CORE_CLASSES) $(EVENT_CLASSES) $(MODEL_CLASSES) $(RENDERER_CLASSES)
$(JAVA_EXE) -classpath $(CLASSPATH) de.progra.charting.test.GraphFrame
$(JAVA_COMPILER) -classpath $(CLASSPATH) $<
I just though a bit about your feature requests and how to implement them. In the recent CVS commits I already corrected most (basically all I hope) of the bugs you noted. I extended the TestChart class to create a full set of test images in the userhome dir (no absolute paths left) and I added a ChartEncoder class for the Image encoding.
Now to the new features we both would like to see.
All the Renderer API stuff like curves, splines, interpolation (what is Catmul-Rom interpolation?) is pretty straight forward. It just needs some Renderers. All Renderers are pretty simple yet, and they need to get more parameters, e.g. line style, plot style etc.
3D Renderers should work the same way, the PointToPixelTranslator would need to be extended to support 3D point translation. Rotating and stuff could be done by passing a rotating matrix to the CoordSystem which the Translator could use. THis would be fancy in interactive use.
The zooming could be implemented by setting value limits in the ChartDataModel. By now, they're computed from the existing values or they're automatically rounded. They could be set manually too.
Creating an Panel to select the Renderer properties is easy then.
Now to the Graphics. Painting horizontally or vertically could be done by rotating the Graphics object of the Coordinate System. THis would be easy. I'm not sure if that's what you mean though. Column Chart as opposed to Bar Charts are usually painted horizontally. I've never seen a vertical line chart though. It might get more complicated if it doesn't suffice to rotate the whole image, the Renderers would need to handle this alone.
You mentioned general angle text marks for bars and points. Generally, it should be possible to highlight a column in a special DataSet. This could be done by providing a text (with an angle) and a highlighting color. Same applies for the axes, although they already have text marks (or do you mean extra marks?), they need an angle.
The movable title and legend in the ChartPanel is pretty simple too. Needs some rendering in the Panel but basically it is necessary to disable the automatic layout in the DefaultChart and to set bounds alone.
That's about it for the moment. I'm working on a more thorough design.
thank you for your prompt responses and good work on notes. Unfortunately
I can't post this message to OpenDiscussion forum (doesn't work today),
so I posted it directly.
I have looked at java.geom classes. I suppose some new features and
classes can be used in jopenchart with advance.
interface of PointToPixelTranslator may be replaced with
java.awt.geom.AffineTransform - it is general 2D transformation
and can be used also for transforming from "world" coordinates
to pixel coordinates of graphics device. When mapping object
into pixels special issue of aliasing arise, but it is more
rendering than transforming problem (see next paragraph).
Advances: - predefined transformations; easy to use composition of rotation,
- performance - there are several functions for transforming
coordinates (it can be calculated for arrays,
transform(Point2D src, Point2D dst) without creating new
instances of Point2D for each converted point...
When rendering 3D charts, 2D transformation can stay unchanged, but
before this transformation to pixel coordinations will be added
some 3D projection. My conception is, that every 3D object consist of
triangles and return to rendering method list of them. Before rendering
must be decided visibility (in this moment I don't know which technique
will be more suitable - whether Painter algorithm or Z-buffer)
painter alg: http://www.cs.unc.edu/~davemc/Class/136/Lecture19/Painter.html
visible surface determination: http://www.siggraph.org/education/materials/HyperGraph/scanline/visibility/vsible0.htm
a) using painter algorithm
After selecting visible triangles (some can be divided by algorithm)
projection to 2D triangles is done still in world coordinates and
points of these triangles are at the end converted with AffineTransformation
to pixel coord. and rendered (with antialising switched on).
b) using z-buffer algorithm
without hardware support is this most common method probably rather slow
Using some kind of transformation for each point of scene leads also to Z-buffer
for determining visibility (or sort all points of scene by z-axis and draw them).
I fear that these approaches can't be used for performance issues not only
in interactive mode but at all.
2) antialiasing and primitives rendering
Using java.awt.shape is a question. For rendering primitives (lines, points, curves)
it has several pluses: antialiasing (setRenderingHints for rendered Shape)
stroking (createStrokedShape(Shape p)) for several line types
existing objects (Polygon, RectangularShape, Rectangle, Line2D,
CubicCurve2D, Area, GeneralPath, QuadCurve2D)
There can be used adjustable flatness (important for
zooming)(FlatteningPathIterator). Round pieces of path
are drawed with Quad and Cubic Bernstein polynomial.
Some interactive examples of Catmul-Rom and Bezier splines
Till now it is all about data visualisation without marks, axes and legends. I think that these
matters can be separated and can wait to talk about them after finishing data visualisation
I considered your remarks concerning the 2D transformations and I made a first implementation using AffineTransform. It works very well indeed and it can make a lot of things much easier.
I think things should be changed the following way:
There will be two AffineTransforms one for each y-axis. (They're in some way public to all classes)
They will be computed when Chart.render() is called.
The CoordSystem then only needs to draw its axis without caring for all that. It just calls something like paint(Line2D from max_x to min_x). Probably it will intersect that with the InnerBounds or something.
The Renderers will do the same things. They transform 2D objects (mostly I used them, but not always, I know) and probably will also check, so they're in InnerBounds.
Depending on the DataSet look defined in the RowColorModel they will draw StrokedShapes.
Upon Panning or Zooming in the Swing interface the AffineTransform will be changed.
ChartDataModels will need methods to manually set the maximum and minimum values to support zooming.
And the RowColorModel will be extended to assign Strokes, Patterns/FillColors and Colors to certain DataSets.
That's it for now.
PS: I received several e-mails of people who wanted to contribute.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.