Looking for test results, bugs, new features

S. Müller
  • S. Müller

    S. Müller - 2001-10-28


    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

    • Lubos Karasek

      Lubos Karasek - 2001-10-30


      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
      3) comments

         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

      Lubos Karasek

      • S. Müller

        S. Müller - 2001-11-01

        Hi Lubos,

        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.


        Sebastian Mller

        • Lubos Karasek

          Lubos Karasek - 2001-11-05

          Hi Sebastian,
             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.
          Lubos Karasek

    • Lubos Karasek

      Lubos Karasek - 2001-11-08

      Hello Sebastian,
        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[]
      required: float[]
              pymodel = (double[])interp.get("model", double[].class);
      de\progra\charting\test\PythonTest.java:70: incompatible types
      found   : double[]
      required: float[]
              pycolumns = (double[])interp.get("columns", double[].class);

      LineChartRenderer constructor
      It is possible to create LineChartRenderer with constructor
      LineChartRenderer(ChartDataModel model, RowColorModel rcm) and
      then collaps on missing PointToPixelTranslator

          at de.progra.charting.render.LineChartRenderer.render(LineChartRenderer.java:67)
          at de.progra.charting.DefaultChart.render(DefaultChart.java:136)

      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 = \ de\progra\charting\AbstractChart.class \ de\progra\charting\Axis.class \ de\progra\charting\ChartUtilities.class \ de\progra\charting\Chart.class \ de\progra\charting\CoordSystem.class \ de\progra\charting\DefaultChart.class \ de\progra\charting\Legend.class \ de\progra\charting\PointToPixelTranslator.class \ de\progra\charting\Title.class

      EVENT_CLASSES = \ de\progra\charting\event\ChartDataModelEvent.class \ de\progra\charting\event\ChartDataModelListener.class

      MODEL_CLASSES = \ de\progra\charting\model\AbstractChartDataModel.class \ de\progra\charting\model\ChartDataModelConstraints.class \ de\progra\charting\model\ChartDataModel.class \ de\progra\charting\model\DataSet.class \ de\progra\charting\model\DefaultChartDataModel.class \ de\progra\charting\model\DefaultDataSet.class \ de\progra\charting\model\FunctionPlotter.class \ de\progra\charting\model\ObjectChartDataModel.class

      RENDERER_CLASSES = \ de\progra\charting\render\AbstractChartRenderer.class \ de\progra\charting\render\AbstractRenderer.class \ de\progra\charting\render\ChartRenderingHints.class \ de\progra\charting\render\InterpolationChartRenderer.class \ de\progra\charting\render\LineChartRenderer.class \ de\progra\charting\render\PieChartRenderer.class \ de\progra\charting\render\PlotChartRenderer.class \ de\progra\charting\render\Renderer.class \ de\progra\charting\render\RowColorModel.class

      SERVLET_CLASSES = \ de\progra\charting\servlet\ChartServlet.class

      SWING_CLASSES = \ de\progra\charting\swing\ChartPanel.class

      TEST_CLASSES = \ de\progra\charting\test\BarGraphTest.class \ de\progra\charting\test\Bar2GraphTest.class \ de\progra\charting\test\CircleGraphTest.class \ de\progra\charting\test\GraphFrame.class \ de\progra\charting\test\PythonTest.class \ de\progra\charting\test\TestChartDataModel.class \ de\progra\charting\test\TestChart.class
      #not used $(TEST_CLASSES) $(SERVLET_CLASSES)

      run_test: de\progra\charting\test\GraphFrame.class
          $(JAVA_EXE) -classpath $(CLASSPATH) de.progra.charting.test.GraphFrame

          $(JAVA_COMPILER) -classpath $(CLASSPATH) $<

      Lubos Karasek

    • S. Müller

      S. Müller - 2001-11-13

      Hi Lubos,

      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.


      • Lubos Karasek

        Lubos Karasek - 2001-11-21

        Hello Sebastian,

        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.

        1) transformations
            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,                
            translation, scale
                       - 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

        regards  Lubos

    • S. Müller

      S. Müller - 2001-11-30

      Hi Lubos,

      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.

      Cheers, Sebastian

      PS: I received several e-mails of people who wanted to contribute.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks