chart-fx most active compared to its alternatives? Try to realize simple real-time candlesticks, any alternative is fine.

[yezhengli-Mr9]

By checking,chart-fx most active compared to its alternatives? Try to realize simple real-time candlesticks #641 (or #643) #642 , any alternative is fine.

Chart performance comparison for popular JavaFX, Java-Swing, C++/Qt and WebAssembly-based implementations: ExtJFX, ChartFx, HanSolo Charts, JFreeChart, JDataViewer, QCustomPlot, Qt-Charts, WebAssembly. The last Qt Charts entries show results for 100k data points being updated at 25 Hz

0. not considering python or R right now since feel they are for batch data analysis mostly.
1. ExtJFX last updated on Mar 01st 2019.
2. HanSolo Charts last updated on Dec. 13th 2022
3. JFreeChart last updated on Jan. 08th 2023
4. JDataViewer, even official release page was last modified on 2019-02-21.
   
5. QCustomPlot c++
6. Qt-Charts c++
7. WebAssembly c++

[raven2cz]

I have fairly extensive personal business frameworks, and I thought I would dedicate at least a substantial part of the foundation to open source. Java and JavaFX are closest to my internal libraries, so chart-fx was a good choice, unfortunately it's not exactly tailored to the business style, rather for measuring purposes, but their optimization for rendering speed and the way some renderers are processed is very close to me. There weren't many options in this field.

The C++ language is not much of an option anymore, in terms of the possibility of memory leaks, especially in the open source environment, they seem very dangerous to me, especially for business purposes. I would rather choose rust, but just a few years ago it was more of a dream than reality.

However, I have not finished my work, I am missing the adoption of volume profiles and foot charts, and some adjustments, especially of time segments, which chart-fx does not yet have.

In the end, however, it is only about the rendering part, not about taking over the execution platform or computing platform. Although I "sampled" a fairly huge part in tests for display, especially real-time processing for numbers bars.

[yezhengli-Mr9]

Thanks @raven2cz, I am for personal use and in short term will stick to java (more friendly for cross-platforms, macbook, linux than, at least, c/c++);

• Speaking of "real-time", 1-minute delay is fine to me. It suffices for me to use bars within one day, that is at most 60*24= 1,440 bars so far. Do not think I will look over more than five business days in the short term.
• at least timestamp conversion and alerts setups in java are relatively doable in java;
• indeed used to consider c++, but thanks for your professional suggestion (then to give up c++ in short term; also remember Qt4/5 takes long to install on macbook then? -- correct me if I am wrong).
• can consider rust later.

Volume profiles: volume profiles are beneficial for me in long term #294 while short-term I am to put effort in stop losses #641 in terms of regression testing (for forecasting) and visualization --visualization seems important for insights and backtesting.

Foot chart: I do not have API for historical footprint chart, only streaming footprint data; consequentially, personally not considering foot charts so far.

[yezhengli-Mr9]

Might be interested in volume profiles after finishing some fundamental prototypes on my end~

[yezhengli-Mr9]

adoption of volume profiles

nterested in generating on right side a projection chart of volume (delta) in the upcoming weeks for

chart-fx/chartfx-samples/src/main/java/io/fair_acc/sample/financial/FinancialRealtimeCandlestickSample.java

Line 49 in ed86318

public class FinancialRealtimeCandlestickSample extends AbstractBasicFinancialApplication {

~although I am still resolving #647 at least for this week.
priority seems lower than volume delta and foot(print) charts (better in relatively real time).

[yezhengli-Mr9]

volume delta and foot(print) charts (better in relatively real time)

Interested in volume delta and foot(print) charts (better in relatively real time, interested in observing their values for several segments/ time intervals within each day-- for example, 3-5 segments/time intervals within each day) in upcoming weeks, so feel still have to fix #647 first.
Put on hold due to algorithm's logic change.