Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Financial Charts - realtime processing, re-sample live demos, improved renderers, navigation etc. #326

Merged
merged 8 commits into from
Dec 8, 2020

Conversation

raven2cz
Copy link
Contributor

@raven2cz raven2cz commented Dec 5, 2020

Add next features and improvements for financial charts.

  • Tick OHLC processing demo with re-sample support. Real-time processing.
  • Improved renderers - better calculation of bars distances, support for y-range min-max feature.
  • Better navigation for financial charts, can be tested in new sample for real-time processing.
  • YWatchValueIndicator for better visualization of y-values and auto handling by close prices. Add to the same sample as before.
  • OHLC domain objects prepared for volume profiles, range bars, foot prints, market profiles (domain objects are part of this commit).
  • Better css styling prepared. Usage for value and range indicators for Support/Resistance levels. Add support for financial themes.

@codecov
Copy link

codecov bot commented Dec 5, 2020

Codecov Report

Merging #326 (33babea) into master (20ae707) will increase coverage by 0.24%.
The diff coverage is 85.15%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #326      +/-   ##
============================================
+ Coverage     51.59%   51.83%   +0.24%     
- Complexity     7266     7313      +47     
============================================
  Files           393      394       +1     
  Lines         41072    41189     +117     
  Branches       6611     6627      +16     
============================================
+ Hits          21190    21351     +161     
+ Misses        18376    18333      -43     
+ Partials       1506     1505       -1     
Impacted Files Coverage Δ Complexity Δ
...rt/renderer/spi/financial/CandleStickRenderer.java 89.67% <50.00%> (+2.74%) 31.00 <0.00> (+1.00)
.../chart/renderer/spi/financial/HighLowRenderer.java 86.39% <50.00%> (+3.63%) 20.00 <0.00> (+2.00)
...derer/spi/financial/AbstractFinancialRenderer.java 88.15% <83.67%> (-1.32%) 16.00 <9.00> (+9.00) ⬇️
...ava/de/gsi/chart/plugins/YWatchValueIndicator.java 87.32% <87.32%> (ø) 16.00 <16.00> (?)
.../spi/financial/css/FinancialColorSchemeConfig.java 90.90% <100.00%> (+0.43%) 26.00 <0.00> (+1.00)
...java/de/gsi/chart/axes/spi/DefaultNumericAxis.java 71.48% <0.00%> (-2.48%) 66.00% <0.00%> (-2.00%)
.../main/java/de/gsi/chart/axes/spi/AbstractAxis.java 76.26% <0.00%> (-0.15%) 182.00% <0.00%> (-1.00%)
...hart/plugins/measurements/DataSetMeasurements.java 75.77% <0.00%> (+0.34%) 153.00% <0.00%> (+2.00%)
...n/java/de/gsi/chart/renderer/spi/GridRenderer.java 81.94% <0.00%> (+0.92%) 47.00% <0.00%> (+1.00%)
... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 20ae707...33babea. Read the comment docs.

@lgtm-com
Copy link

lgtm-com bot commented Dec 5, 2020

This pull request introduces 1 alert when merging 57361ae into 20ae707 - view on LGTM.com

new alerts:

  • 1 for Potential input resource leak

@lgtm-com
Copy link

lgtm-com bot commented Dec 6, 2020

This pull request introduces 1 alert when merging 2130e88 into 20ae707 - view on LGTM.com

new alerts:

  • 1 for Potential input resource leak

@raven2cz raven2cz marked this pull request as ready for review December 6, 2020 09:24
Copy link
Member

@RalphSteinhagen RalphSteinhagen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very nice PR, only minor things.
The main questions/comments:

  • new interface -> is this really necessary?
  • authorship (not critical) -> feel free to claim your @author JavaDoc tags.
    See other comments/questions for details.

FileInputStream fis = new FileInputStream(f);

//----------------------------------
fileChannel = fis.getChannel();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

potential resource leak fis being opened in this function and not clear that it is closed elsewhere. Try-with-resources and auto-close wouldn't probably work here.... 🤔

Since this is an example, it's not that critical but would be -- in case this is a false positive -- to suppress the LGTM warning.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it cannot be closed in the same method because it is a opened stream for ohlc realtime processing. There is another method for closing stream in the finished/exit parts of sample demo. LGTM cannot recognize this handling by some simple checking of try-resource. The LGTM suppress tags are already added.

@@ -0,0 +1,135 @@
/**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe add your @author tag below and reference to CERN behind the original primary author

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super, changed according your proposal.

/**
* OHLCV Listener about structure changes.
*/
public interface OhlcvChangeListener {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this new interface really necessary? As an alternative: would it be an option to derive a new event type from 'UpdateEvente.g.IOhlEvent' and -- as an API contract -- to put the IOhlcvItem to the event's payload? The rationale is to minimise the number of public API/interface definitions that need to be maintained long-term... in any case, am open for discussion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is perfect, reviews are very important. Thanks! Removed. Not necessary. Refactored for an internal usage in the example only!

@lgtm-com
Copy link

lgtm-com bot commented Dec 8, 2020

This pull request introduces 1 alert when merging 33babea into 20ae707 - view on LGTM.com

new alerts:

  • 1 for Potential input resource leak

Copy link
Member

@RalphSteinhagen RalphSteinhagen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the modifications and comments. If you are OK with this, I'd squash-merge it into master. We would do a micro-release in the coming days...

@raven2cz
Copy link
Contributor Author

raven2cz commented Dec 8, 2020

Thanks for the modifications and comments. If you are OK with this, I'd squash-merge it into master. We would do a micro-release in the coming days...

Thank you. Yes, squash-merge.
Next steps, before next fin.charts, there is necessary renderer / visualization of orders and positions entry/exits in the actual charts, and maybe by table way too. I see that some renderers support table structure too. These orders are not large implementation, but there has to be defined correctly several attributes (cca 15-20 atrtrs) for each executed position. So, graphic is not complicated, but domain object includes few attributes which have to be presented by positions in the chart or alternative table view (optional).

@RalphSteinhagen RalphSteinhagen merged commit c0ea477 into fair-acc:master Dec 8, 2020
@wirew0rm
Copy link
Member

wirew0rm commented Dec 8, 2020

Hey, didn't hava a chance to look at it in detail, but what I looked at looked nice 👍

Regarding tables, this is not done as a renderer, but as a dedicated plugin (TableViewer for just showing data as a table and EditDataSet for editing points). As it was developed before the DataSet Interface was extended to multiple dimensions, it currently only supports X/Y data. It would be nice to extend it to multidimensional datasets and to take the label/unit information from the axisDescriptions into account.

@RalphSteinhagen
Copy link
Member

@raven2cz just as a note/addition to what @wirew0rm mentioned:
It's equally possible to implement it as a Renderer.

The interface

List<DataSet> render(GraphicsContext gc, Chart chart, int dataSetOffset, ObservableList<DataSet> datasets);

provides access to the Canvas (via GraphicsContext) as well as the corresponding Chart and all of its sub-component including notably the Pane getPlotForeground() which is drawn on top of the chart and could hold also a custom rendered table component.

The primary reasons why we (originally) implemented it as a 'plugin' was to adorn the chart and to allow the user to quickly switch the table 'on' or 'off' while still relying on the same generic DataSet that is drawn in the background and also because we didn't have the DataViewer functionality yet at that time.

Using the DataViewer, this could be also implemented externally by switching between two DataViews, one with the chart, and the other one holding the table. This would also correspond to a more classic JavaFX/UI design.

N.B. the latter option should be also more performant since it removes/adds the chart from the JavaFX scenegraph when needed which minimises unnecessary draw routines (if you have a lot of data points). The Renderer/ChartPlugin option has the advantage that one does not have to synchronise the attached DataSets between two Pane components.

Maybe have a look at the DataViewer and let us know your view/angle. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants