DEV Community: Andrew Bt

Powering Research. Development. Innovation worldwide

Andrew Bt — Tue, 24 Jun 2025 15:06:38 +0000

At SciChart we are proud to support Innovation & Research worldwide. As part of an educational license program, we grant licenses in many cases for free, or at low cost to Universities for non-profit R&D worldwide. We have astounding list of over 145 Universities which use SciChart in their projects, including MIT, Stanford, Imperial College London and more. These projects have powered cutting-edge research and advanced the frontiers of science, using our high-performance, real-time charting libraries to visualise data.

List of Projects Showcased in this Article

We’ve taken a handful of the best student & University research projects to showcase in this article. For a look at what SciChart can do, and some of the incredible research, read on!

Project 1: The University of Illinois reduced cancer screening time from weeks to hours in research of methods being used for classification of tissue thin sections identifying tumorous regions.
Project 2: The NTNU Norwegian University students built an electric race car from scratch and participate in Formula Student every year. They have created their own dashboard to monitor and adjust car performance with the data from more than 300 sensors.
Project 3: A FH Joanneum University student developed a wearable device and App, enabling researchers to conduct vital signs analysis from raw sensor data for personal health. The main goal is to increase diagnostic accuracy.
Project 4: A student at Vellore Institute of Technology and created a low-cost non-invasive healthcare solution for the clinical needs of India and the rest of the world, a cheap portable ECG device that could achieve medical grade clarity with realtime data plotting.
Project 15 MIT students have created a robotic smart shoe with the skin surface like sensors. Its telemetry data prevents robot from falling. The ultimate goal is to assist elderly with fall prevention and athletes with training data.

Project 1: High-Definition Realtime Visualization of IR QCL Spectroscopy for Diagnostic Tissue Imaging

The University of Illinois departments of Bioengineering, Mechanical Science & Electrical Computer Engineering were researching alternatives to Fourier-transform infrared spectroscopy for use in Medical Diagnostics and methods being used for classification of tissue thin sections identifying tumorous regions.

Despite exponential growth of the field and its world-wide research, the clinical sphere has been limited by data management. With over a 100 million data points generated in realtime, current imaging technologies were limited to less than 1% of the data set.

This study turned into the cutting-edge research project where SciChart’s WPF charting library is used to display Realtime High Definition Heatmaps from Quantum Cascade Laser (QCL) Infrared (IR) Spectroscopy.

SciChart helped with handling over 1 million points of data in real time with the capacity to increase to 10 million. This allowed the advent of HD Realtime IR imaging and reduced the screening time from weeks to hours. In this field time is indeed the invaluable resource.

Project 2: Data visualization of more than 300 race car sensors

Revolve team from NTNU used SciChart’s High Performance WPF Charting Library to handle their complex data from over 300 sensors in their electric Race Car.

Revolve NTNU Norwegian University of Science & Technology is an independent student organization engaged in Formula Student, Europe’s most established educational motorsport competition. Creating new iterations of their Race Car each year, Revolve needed to be able to visualization their multi-stream, high-bandwidth data from their hundreds of sensors in Realtime to ensure top performance and allow for torque vectoring and testing of their car.

Realtime race visualisation for Formula race cars using SciChart. Showing Battery Management System Heatmap, Scatter Maps, Damper Rate, Realtime Laps Map, Break Sensor Data and more.

The charting library allowed the team to do performance analysis and testing, they are ranked number 10 in the world now and surely are some of the most talented engineering students in the world.

Project 3: Medical-grade wearable device that offers real-time physiological data acquisition

A student from FH Joanneum University of Applied Science has developed an Android Application to record acquired sensor data via Bluetooth and to allow synchronization with the Empatica(E4) and Google Fit cloud storage solutions.

The E4 is a medical-grade wearable device that offers real-time physiological data acquisition.

Since there is no universal standard for data exchange the goal is to enable the researchers to conduct in-depth analysis from the raw sensors data visualised and exported. The SciChart Android Charting library was used to visualise the raw data received from sensors via Bluetooth.

The E4 wearable device and the Android application data visualization
It measures blood volume pulse (BVP), from which heart rate variability can be derived. The 3-axis accelerometer captures motion-based activity. An EDA sensor (GSR Sensor) measures the constantly fluctuating changes in certain electrical properties of the skin. An infrared thermopile reads peripheral skin temperature.

As the result of the study the heart rate variability (HRV) was calculated using the interbeat interval between all successive heartbeats.

Needless to say, that the implications of the personal health devices can increase diagnostic accuracy, enhance physician efficiency and allow more convenient data collection.

Project 4: Visualization of ECG signals in Realtime on a low cost portable device

A student at Vellore Institute of Technology, Vellore as a part of Cardea Labs & Cardea Biomedical Technologies Pvt. Ltd team had a challenge to create a low-cost non-invasive healthcare solution for the clinical needs of India and the rest of the world. It had to be an affordable portable ECG device that could achieve medical grade clarity, therefore the challenge was in the reliable realtime data visualization with smooth interactions.

SciChart’s WPF extensive charting library was used to create the FIFO functionality required, which generated a Realtime scrolling ECG monitor. The chart is dynamically updating at 250 points per second with data acquisition through Bluetooth connection for an ECG device derived from the miBEAT hardware platform.

This was combined with export function that allowed users to export in numerous formats, so the data could be collated outside of the application. The session window allows to Pan, Zoom & Scroll making the UI intuitive and user friendly, all this being used on smaller portable devices.

From the Author
My students’ years were enriched by being a part of Students’ Organizations. I was a member and a leader of a local group of the Board of European Students of Technology – a non-profit organization with the mission to empower diversity. I also joined the Enactus team at Graceland University during my exchange year abroad program. Enactus is an organization has the vision to create better more sustainable world. These experiences shaped me and my career as it is now. This is where I gained my skills to land the first job and my drive to progress at what I do.

I am happy to work at a place that supports students as much. SciChart has an academic free license for the students’ university projects and research. SciChart is an innovative company at its heart and investing into students, who have the spirit and unstoppable willingness to make a difference gives us an interesting mix.

Project 5: MIT / Realtime Android charting for Robotics Telemetry

MIT Biomimetic Robotics Lab used SciChart for Android to display and interpret Realtime telemetry data from Smart shoe sensors designed to capture measurements of force-data during movement.

Organic organisms contain an abundance of surface skin sensors that can determine pressure, vibrations and forces which in turn feedback and allow calibration of movement. The Biomimetic Robotics lab at MIT aimed to develop a similar multi-axis force sensor for use in the next generation of legged robots by mapping the local sampling of stress inside their custom polymeric footpad.

SciChart’s Android charts were used in the application for reading and visualising multiple streams of data at 1kHz amounting to hundreds of thousands of data points, collected from smart shoe telemetry.

The team’s goal is to use these force sensing shoes not only in robotics, such as the famous Cheetah Robot, but also to help assist the elderly and disabled during walking for fall prevention and mitigation as well as to provide athletes with training data.

Enjoyed our Case Studies?

Find more case studies here: Desktop Case Studies, Mobile Case Studies, Consultancy Project Case Studies.

p.s. Interesting, that the sphere where students’ projects have been performed align perfectly with the domains of commercials SciChart customers, including 60% of top global semiconductor companies, 80% of global MedTech, 80% of top US Banks, All top F1 Teams, Top Global Petrochemical companies and thousands more.

p.p.s.Vrije Universiteit Amsterdam, ranked in the top 100 of global universities is now teaching SciChart to its computer science students in the construction of real time applications. SciChart is being taught at several leading educational establishments meaning that our software is being used to train the next generation of the workforce in cutting edge technology.

SciChart – The Fastest WPF Charts. Period. 2021 Test Results Update

Andrew Bt — Tue, 24 Jun 2025 14:55:00 +0000

Introduction

Performance has always been one of the main aims of SciChart’s WPF chart libraries. Our customers include engineering, financial and medical companies who demand the very best performance, flexibility, reliability, integrity of our staff as well as excellent customer service.

We’re proud to announce that SciChart WPF is used by not one, but directly by five Formula One teams! As well as indirect usage in all F1 teams via vendor software in some shape or form.

Defence companies and even governments that demand reliability of our software and integrity of our engineers are repeat customers of SciChart. Medical companies who create cutting edge medical-devices, participate in bleeding edge cancer research use SciChart. They all require high performance.

SciChart is used in demanding applications. 5 Formula One teams use SciChart!

Having the Fastest WPF Charts is a great selling point but it’s not the only reason to use our Software.

SciChart WPF is also incredible easy to use, flexible and has a depth of features like no other.
SciChart has an intuitive, XAML & MVVM-friendly API out of the box.
Hundreds of customers rate SciChart 5-stars so we’re doing something right.

You can find more reasons at Why SciChart: The Best WPF Charts.

Nevertheless, WPF Chart Performance matters to our customers, so we test exhaustively to ensure that SciChart WPF has the best possible performance your demanding applications.

So how do we do that?

SciChart WPF – Fastest WPF Charts by a mile

We’ve previously talked about SciChart WPF being the Best WPF Chart, and the Fastest WPF Chart control. If you haven’t read it, have a look at SciChart WPF v6 ‘Xccelerated Edition’ Up to 100x (10,000%) Faster WPF Charts where we discuss why we focussed on improving performance in 2019/2020, the steps we’ve taken to ensure that every aspect of our pipeline is optimised and some test results vs. competitors.

Using claims such as ‘Best’ or ‘Fastest’ on our website and marketing is bold but they are backed up by solid data! We’ve carried out extensive performance testing in-house. I’m going to share some of the latest test results below.

Updated WPF Chart Performance Comparison (November 2021)

It’s worth a note that Open Source WPF charts and almost all Commercial WPF Charts don’t come close to SciChart’s performance. As a result they cannot even register on our demanding test suite. So instead, we’ve compared the latest test results vs. our strongest competitor in terms of performance.

We’ve constructed a WPF Chart Performance Test Suite with over 70 test high-stress test cases covering a wide variety of conditions to assess performance between SciChart & ‘Competitor A’.

Test cases are varied and include:

Thousands of line series. Up to 4,000 series on screen with 4,000 datapoints per series.
Realtime line series (scrolling, old data discarded). Up to 10 Billion datapoints on screen with 1 Million new data-points per second.
Realtime line series with old data kept on screen. Chart auto-fit enabled. Up to 25 Million new data-points appended per second.
Scatter charts & Scatter (XY) line series. Up to 30 Million data-points.
Other WPF chart types including Candlestick, Columns, Bars, Area, Mountain. Up to 30 Million data-points.

Here are the test results below:

SciChart vs. ‘Competitor A’ 2021 Test Results

WPF Chart Performance Comparison between SciChart WPF & Competitor A, November 2021.

Note: Why have we hidden the test case names? Because in-depth expert analysis of chart performance is valuable and we don’t want to tip our competitors off!

WPF Chart Rendering Speed: FPS or ‘Frames per Second’

On the Green/Yellow/Red column you can see FPS. This stands for ‘Frames per Second’ and is a measure of how many times the chart draws per second. This number is averaged out over the window for each test.

The maximum FPS for SciChart is capped at 60 FPS
The average FPS for SciChart over 70 test cases is 47 FPS
The median FPS for SciChart over the test cases is 58.2 FPS

Meanwhile …

Competitor A also achieved a max of 60 FPS (capped at 60)
An average of 22 FPS
and a median of just 9 FPS

Over 70 demanding WPF Chart Performance test cases, SciChart outperformed the strongest competitor on the market by an average (mean) of 455% faster rendering. A max of 3,893% faster rendering and a median of 156% faster rendering was observed in like-for-like WPF Chart Performance tests.

Note: Several tests performed by Competitor A have FPS=0. This means that a prior test scored low, hanged or crashed and the test was halted for this test group. In this case the SciChart performance increase was effectively infinite, so how can we calculate speed improvement?

What we can do is multiply FPS x Number of data-points in the group to determine a speed score or ‘Datapoints per second’. Then, calculate a maximum speed increase based on which chart was able to render or draw the highest number of data-points.

SciChart (Left Column) vs. Competitor A (Right Column). Tests in a Group with an FPS below 2 or where the competitor chart failed were halted

Each Test group was a specific WPF Chart test case. In Test Group 5, Competitor A struggled to draw 1,000,000 (1 Million) data-points at 2 FPS for this test case while SciChart was able to draw 10,000,000 (10 Million) datapoints at 58.7 FPS.

Thus the Data-point per second calculation is:

SciChart: 58.7 x 10M = Can render 587,000,000 data-points per second
Competitor A: 2 x 1M = Can render 2Million data-points per second
Result: SciChart is up to 293.5 x faster for this test case!

Test Group 6 was another WPF Chart Type. Competitor A struggled to draw only 10,000 data-points at 1.5 FPS while SciChart was able to draw 10,000,000 (10 Million) datapoints at 58.5 FPS.

SciChart: 58.7 x 10M = Can render 585,000,000 data-points per second
Competitor A: 1.5 x 10k = Can render 15,000 data-points per second
Result: SciChart is up to 39,000 x faster for this test case!
So there you have it.

In Demanding WPF Chart Performance tests, SciChart 🥇 was able to outperform ‘Competitor A’ (the 2nd fastest WPF Chart 🥈) by rendering 39,000x more data-points per second in one test case and 293.5x more data-points per second in another test case, by using the Datapoints Per Second methodology above.

WPF Chart CPU Usage

CPU usage is also important to our users. What if the chart is the fastest but uses all the CPU resources, making the rest of your application slow?

SciChart is strictly single threaded for rendering, and while we allow you to append data from a background thread (SciChart WPF is thread safe: we handle the locking & synchronisation), there’s very little parallel processing inside SciChart itself. Instead we favour fastest single-threaded path for code, using low-level optimisations as part of our Visual Xccelerator® Engine typically only found in the gaming industry.

SciChart CPU usage is on average 5% lower than competitor A for the 70 WPF Performance test cases we carried out.
SciChart CPU usage is a median of 7% lower over the test cases carried out.

WPF Chart Memory Usage

Memory in a C# .NET application is also very important. What we found in our testing was that SciChart used considerably less memory than Competitor A to achieve it’s record high performance, meaning there is more memory available for the rest of your application.

At SciChart we’ve optimised not only rendering performance (being fully GPU accelerated), CPU usage (using low-level gaming industry optimization techniques) but also memory making us suitable for the most demanding applications.

SciChart: Experts in High Performance Charts & Data Visualization

At SciChart we are experts in our field. I personally hold a Masters Degree (MEng) and PhD in Electronics, covering the topics of electronic hardware design, embedded systems and signal processing. You can see this post on Linked In here with some of the work I’ve done in this field.

I’ve designed pieces of low-cost electronic measurement hardware which outperformed much more expensive scientific instruments in terms of accuracy. I’ve written algorithms for Fast Fourier Transform on GPUs before the days of nVidia Cuda or OpenCL, have coded several algorithms and hand-tuned the performance of critical sections of C++ & C# code. My team and I understand at a very low level what’s happening on-chip when you process data or perform certain operations in software.

At SciChart we are a team of low-level software optimisation experts. Our experience spans not just C# .NET and WPF, but also Graphics, GPU acceleration, languages such as C++, Swift, Kotlin, Typescript, multiple 3d libraries such as DirectX, OpenGL/OpenGLES, WebGL, Metal and low level performance optimization techniques used in the gaming industry.

We’ve transferred that knowledge into SciChart to bring you an incredibly complex piece of software which looks simple on the surface: SciChart WPF – The Best (and Fastest) WPF Chart. All in a package which is easy to use and ‘just works’ out of the box.

Do you need more Performance in WPF Applications with Charts?

If you do find a use-case where SciChart performs less than optimal, then do contact us. We often have customers reach out with performance issues but it turns out a small tweak in the usage of the library can result in huge performance improvements.

We’ve also carried out bespoke consultancy work for customers in the F1 sector and Financial services to performance tune their apps. Integrating SciChart to a large or complex app requires sometimes the knowledge from our engineers to get the best possible performance out of the library.

Is WPF Dead? The Data Says Anything But, here’s why

Andrew Bt — Tue, 24 Jun 2025 14:45:49 +0000

TLDR: We review the status of Windows Presentation Foundation (WPF) in 2024 and beyond, whether it’s usage is increasing or declining and if this is a good platform to develop on for the long term. We talk about why WPF is still popular for performance or critical apps, particularly in the scientific, engineering or medical fields, and what alternatives there are for enterprise software development. Plus, our views on the ever changing landscape for desktop or cross-platform application development both now and in the future.

What is WPF?

WPF or Windows Presentation Foundation is a graphical framework by Microsoft for building rich interactive and visually appealing desktop applications. WPF has been around since 2006 where it was first introduced as codename ‘Avalon’ in Microsoft .NET Framework v3.0. Since then, WPF has undergone many evolutions and is actively maintained by Microsoft almost 20 years later! Supporting desktop application development on Windows, WPF is dependent on Microsoft .NET and applications can be built in C# or Visual Basic .NET.

WPF features a declarative markup language known as XAML, allowing clean separation of View (user-interface) and Model (data). It has many benefits such as rich vector graphics, resolution independence, DirectX hardware acceleration, a powerful data-binding engine and the ability to create entirely custom user interfaces or controls via Templates and Styles.

Below we will expand on the reasons why WPF continues to be popular, and what the future holds for this platform.

What are the Alternatives to WPF?

Past & Present alternatives to WPF on the XAML / C# stack in chronological order include:

Avalonia (2011 – present), an open source platform XAML / C# framework
Xamarin (2011 – 2024), a Cross-platform XAML / C# application framework for building mobile apps and desktop apps, which will be deprecated this year
WinRT (2012 – 2015), a Microsoft Windows 8 based replacement for WPF which was ultimately deprecated.
UWP (2015 – present), a Microsoft Windows 10 based replacement for WPF which is still active, but somewhat superseded by WinUI
WinUI (2018 – present), a Microsoft Windows 10 based successor to WPF
MAUI (2022 – present), a Microsoft cross-platform XAML / C# application framework which replaces Xamarin and with a focus on mobile apps
Avalonia XPF (iii) (2023 – present), a 100% feature compatible replacement for WPF by the Avalonia team which allows WPF applications to run on Linux and macOS without code changes.

In addition, there are other cross-platform or desktop frameworks that are not based on C#. These include:

Flutter: A cross-platform Dart framework for building mobile apps
Qt: C++ based user interface framework for cross-platform applications
JavaScript / React: Various flavours of JavaScript (or TypeScript) plus React or React Native allow creating cross platform applications

Is Javascript / React a Viable Alternative to WPF?

This article is primarily focussed on Microsoft or Xaml / C# frameworks, however, let’s cover quickly the topic of whether JavaScript / React is a viable alternative to WPF.

There are many applications which were developed on WPF which could be ported to JavaScript. However, there is still a large subset of applications for which WPF is a great choice vs. JavaScript or browser technologies. Those include, applications which require:
_

Native performance
64-bit memory addressing on the client
Multi-threading and making use of all cores on the client
In addition, there are other advantages of developing for WPF, which are listed below.

What are the Advantages of WPF?

As a C# based user-interface framework with a long track record of stability and performance, WPF has many advantages.

Rapid Application Development

One of the reasons WPF continues to be popular, especially in enterprise and industries is the fact you can click File -> New Project in Visual Studio, write an app, compile it, and deploy it by copying to a shared drive or distribute via clickonce installer. It’s fast & easy.

Compared to the tech-stack of JavaScript apps where you will need to learn React, Redux, Typescript, HTMl, CSS, Node, Npm, REST, Websockets, a server platform, database platform, plus deploy your application to an environment before it’s available to others, it’s clear to see why rapid prototyping or building of internal tools tends to favour simpler alternatives such as WPF.

Mature Toolchain

Tools such as Visual Studio provide a visual designer, hot-reload, visual as well as code debugging.

Extensions like Resharper, NUnit or MSTest allow creating testable applications, supporting Test-Driven-Development (TDD).

Finally, third party tools and a rich ecosystem of third party free or paid components & libraries such as charts, graphs, datagrids on NuGet enhance the development experience further.

C# is a Great Programming Language

With it’s dependence on C# .NET it is possible to create powerful multi-threaded thick-client or thin-client applications in WPF, with best practices in software (such as dependency injection, model-view-view-model or MVVM patterns).

With 64-bit memory addressing in C#, near optimal performance and multi-threading you can build complex and high performing applications in WPF.

Build Complex & High Performance Desktop Apps

WPF continues to benefit from advancements in the evolution of .NET – allowing client / server applications with Azure Functions (Microsoft’s equivalent to AWS) to be written in the same language. Performance techniques like SIMD and vectorisation are now available in C#. Multi-threading and async/await as we mentioned before, plus C++ interop if you need to integrate to legacy code or high performance code.

Many users in the scientific, engineering, medical, automotive, motorsports or aerospace industries cannot sacrifice performance, and WPF gives you just that – full access to low level routines which will utilise the most from your CPU / GPU and disk.

How Popular is WPF in 2024?

In 2024, WPF continues to be popular for enterprise software development, with some estimates saying there are a half a million to one million actively developed applications worldwide.

Despite rumours of WPF’s untimely demise, the data shows a different story.

Below are a few data-points talking about the current state of the platform which shed some light on it’s future.

WPF Activity on Github

WPF was partially open sourced by Microsoft in 2018 (ii), and as of today it’s GitHub repository has 6,700 Github stars, 1,100 forks, 142 contributors and over 5,200 commits spanning a 5 year period.

There are active projects such as Avalonia XPF (iii) which are looking to make WPF into a cross-platform framework. More on this below.

Strong support from the community as well as Microsoft means it’s likely that WPF will be here for many years to come.

Google Trend Searches for WPF vs. WinUI, MAUI

Google Trends (i) is a great tool to estimate the relative popularity of something worldwide and see the search trends over time. On it’s own, in a 5-year time period, there is a slight decline in searches for WPF. However, when compared against search trends for competing platforms such as WinUI, MAUI (Microsoft), Avalonia and Windows Forms, WPF continues to be dominant and show relative strength.

Activity for Nuget Packages

Nuget is the package manager for C# libraries including WPF. You can estimate the popularity of WPF vs. other similar frameworks by looking at download trends of popular libraries.

WPF Toolkit: a collection of free open source controls on WPF such as a DataGrid, ColorPicker and Charts has almost 12 million downloads (iv), and continues to uptrend.

Prism: a popular dependency injection framework has libraries for WPF, Windows (UWP), MAUI and Uno. You can see in the download trends (v), Prism.WPF outstrips all the others by a large margin.

Oxyplot: an open source charting library has implementations for WPF, Windows Forms and Windows (UWP / WinUI). Also here WPF leads the crowd and has the largest number of downloads by all

SciChart: provides a high performance WPF Chart Control which was first released in 2012. On NuGet the package has reached 700,000 downloads, and continues to uptrend strongly – quite a lot for a closed-source commercial library!

Popularity in Enterprise

In 2024, WPF continues to be popular for enterprise software development, with over some estimates showing a half a million to one million actively developed applications and two million developers worldwide.

While not much chatter or excitement for what is no longer a new technology, WPF still has a lot of demand in internal and business-critical applications.

Anecdotally, several recent posters on a reddit topic about the future of WPF (vii) commented very positive things about the framework:

Basically it is a lot more popular than it appears on the outside. WPF is kind of like Cobol. You won’t see many posts about it, but it’s used quite a lot in enterprise and financial institutions for internal applications and tools.

We use it a lot in the automation industry – and after years of using it I like it. We have to live with supporting old WinForms here. It is ok but I like WPF more. WPF is in between the old WinForms and currently still buggy MAUI for me (personally)…

WPF here too, we routinely evaluate alternatives but have never found something that is absolutely better in every way given our requirements.

I’ve been developing WPF desktop applications for the last ten years. I can say that WPF is more popular within “traditional” industries like the banking, medical and defence. So if you see yourself in one of those industries WPF (with MVVM) is a good choice.

Since 2020, I’ve worked on a massive WPF project. If you need to do native windows desktop development, WPF is the best choice in my opinion.

What’s the Future of WPF?

As well as alternative Xaml / C# frameworks, there are some exciting developments which may one day become the future of WPF. One of them is Avalonia’s XPF (iii). Brought to you by the Avalonia team, this is a 100% compatible replacement for WPF’s low level code which runs entirely on Linux and macOS as well as Windows. Users have reported being able to re-target a WPF application using Avalonia XPF and compile / deploy to macOS & Linux in minutes.

Mobile (iOS / Android) and web browser support is on the roadmap from the XPF team, meaning one day we could see a truly cross-platform version of WPF.

Cross-platform may be low on many enterprise WPF developers wish-lists however being able to port applications to Linux just be retargetting / recompiling is a huge value-add for organisations that require the highest possible performance, or OEM deployments into embedded systems which require Linux. Plus, by replacing the legacy DirectX9 renderer with OpenGL / Vulkan, Avalonia XPF conveys several advantages and shows a positive evolution in WPF.

Below here’s a prototype showing SciChart WPF running on Linux under Avalonia XPF. Our team has been actively investigating this and cross-compiling our C++ engine to Linux, abstracting all DirectX calls to OpenGL. We hope to make an announcement soon that SciChart will be available on Linux & macOS under XPF, allowing to developers of embedded systems, OEM applications and performance-heavy scientific and medical applications to target this platform.

Above: SciChart on Linux! Using Avalonia XPF, plus an internal build of our cross-platform engine, we are able to run SciChart’s High Performance 2D & 3D Charts on Linux and macOS

Conclusion

Is WPF Dead?

Far from being dead, we believe WPF will be here for years to come. Here are the key reasons why:

WPF has stood the test of time and is still active in enterprise software development 18 years after first release
It continues to be compatible with the latest versions of Windows and no sign this will change.
WPF is now open source, and has an active Github repository with hundreds of contributors, thousands of stars
Google Trends and NuGet data show WPF packages continues to outpace alternatives in the C# / XAML space such as MAUI / WinUI
Exciting projects such as Avalonia XPF extend the lifespan of existing WPF apps, allowing them to target multi platforms such as macOS and Linux and in future, iOS / Android / Browser

Finally, Our Roadmap

We are making steps now to make the SciChart library platform agnostic and as a first step, will be releasing a version of SciChart to support Avalonia XPF soon.

This will be a drop-in replacement, allowing applications which used SciChart WPF to ‘Just Work’ on Linux or macOS without code changes. We’re excited about this step in our evolution as a large proportion of our customers build for embedded devices, OEM systems or require the highest possible performance – which Linux helps to provide.

From a commercial point of view we are personally yet to see the demand for platforms such as WinUI or MAUI to match or replace WPF, however we are monitoring the situation closely. We are considering ways to make our technology available to more C# / XAML frameworks.

As a whole, we continued to be excited about XAML / C# based frameworks. We see a bright future in scientific, engineering and financial software which require the highest possible performance and will be continuing to invest in them.

Running SciChart WPF on Linux? It’s possible, here’s how

Andrew Bt — Tue, 24 Jun 2025 14:37:18 +0000

Over the years the question has cropped up many times “Can you run SciChart on Linux?”

SciChart – a cross platform chart library with implementations for Windows Presentation Foundation (WPF), JavaScript, as well as native iOS (Swift/Objective-C) and Android (Java/Kotlin) is based on a proprietary C++ rendering engine codenamed Visual Xccelerator®. This provides the speed, performance that SciChart is well known for, but also a secondary benefit is this engine brings a single shared codebase across platforms for drawing high performance scientific, financial & medical charts & graphs with hardware acceleration in DirectX, OpenGL, Metal and WebGL.

As of yet, there is no pure C++ version of SciChart that could run in say, Qt, however, we have been making steps towards Linux support for SciChart.

Read on to learn how…

Why SciChart on Linux?

WPF applications are typically Windows applications, as they require Microsoft .NET and the Windows Presentation Foundation to run. However, a subset of extremely demanding scientific, financial or medical applications require charts that run on Linux. This could be for:

Embedded systems
Custom portable hardware
Electronic test equipment
Radio Frequency or Spectrum Analyzers
Oscilloscopes
Terminals or kiosks in factories, industrial processes or oil rigs
Maritime vessel instrumentation
Aircraft instrumentation

By running Linux on an embedded system the cost basis goes down significantly for manufacturers of embedded devices, who won’t have to pay for a Windows license.

In addition, the RTOS (real time operating system) nature of Linux makes it perfect for high performance, critical embedded systems which require high performance, big-data or real-time charts.

Can WPF Run on Linux?

Microsoft introduced .NET Core in 2014, later superseded by .NET, which aimed to be a cross platform implementation of the .NET Framework. It’s no secret that C# code and .NET has been able to run on Linux (and macOS) for many years, but what about WPF?

According to Microsoft official sources, WPF is only for Windows, as this part of the framework was not ported over to Linux. However, the geniuses at Avalonia have actually achieved something astonishing: they’ve managed to make a completely cross platform framework called Avalonia XPF, a version of the Windows Presentation Foundation that runs using OpenGL instead of DirectX.

What is Avalonia XPF?

Avalonia XPF is a proprietary, cross-platform implementation of Windows Presentation Foundation (WPF) brought to you by the developers of Avalonia UI. This enables full WPF compatibility of legacy and existing applications but allows them to run on Windows, Linux and macOS. It achieves this by substituting the DirectX and MilCore Windows specific functions and routines in WPF for equivalents in OpenGL and C++. The result is, existing WPF applications can be ported to run on Linux, often without any code change and in minutes.

It can’t be stressed enough what an enormous timesaver this is for teams who have large existing WPF applications that want to target multiple platforms.

Introducing SciChart for Avalonia XPF

SciChart has been working with the Avalonia team for some time, to bring you an Avalonia XPF compatible version of SciChart WPF that will run on Linux.

Here’s what we’ve done / how we’ve done it:

Our C++ Visual Xccelerator® engine has been retargeted to Linux and is compiled using CMake
We’ve swapped out all the DirectX rendering in SciChart, for dynamic choosing of DirectX or OpenGL depending on platform.
We’ve built a side-by side solution for SciChart WPF that will run targeting Avalonia XPF, as well as the existing .NET Framework, .NET 6,7,8 etc…
The examples app & demos have all been tested in the new environment.

It’s important to state we had to make almost no code changes to SciChart WPF itself, and no changes to the API. This is a fully 100% compatible version of SciChart that just magically works on Linux, when targetting Avalonia XPF.

Early Preview – SciChart for XPF on Linux

Below, here’s a video of SciChart for Avalonia XPF running on Linux.

We’re using Visual Studio Code to compile the examples / demo application, and run a number of examples inside an Ubuntu VM.

It’s important to note this is the exact same code, and API as SciChart WPF for Windows, meaning your Windows applications will be compatible and able to run on Linux when targeting Avalonia XPF.

The first demo is the Spectrogram (Spectrum Analyzer) demo, showing the real-time capabilities of SciChart for real-time charts on Linux, followed by the ECG Monitor demo, a real-time medical vital signs monitor.

We then showcase the Digital Analyzer Performance demo – a big data demo which loads multiple channels of digital data each with millions (or even hundreds of millions) of data-points. Useful for creating Logic Analyzer hardware.

At the time of writing, all the 2D examples have been enabled. 3D charts and examples also work however we have one or two bugs to work out before releasing them.

Beta Version

A BETA version of SciChart for Avalonia XPF, with 100% compatible code and API to SciChart WPF will be available soon.

We’re going to be publishing a BETA with the demos example application that you can run on both Windows and Linux under the Avalonia XPF framework.

Pricing and Licensing is to be announced, but during the BETA phase we will be making long-term trials available to customers of SciChart WPF in order to try out and provide feedback.

How is Oil and Gas Wellsite Data Visualized?

Andrew Bt — Tue, 24 Jun 2025 14:33:36 +0000

Visualizing wellsite data is highly complex due to the high volume and variety of data. Diverse data sources need to be visualized concurrently and often in real-time to enable rapid decision-making in safety-critical settings. With vast data sets accrued from multiple locations in varying time frames, visualization helps analysts interpret this complex data.

This guide explores the available coding languages and devices, as well as specific examples of charts and the types of data and metrics they can display to help data scientists and decision-makers work together to make profit-based decisions.

Which Language and Platform Should You Use?

The programming language and platform you want to use depends on the specific use case. Data sets can be processed and displayed using high-performance charting solutions on WPF and JavaScript—both allow installations on common hardware. Benefits of JavaScript include its versatility as a browser-based solution as well as a remote device solution, meaning custom, embedded or web-based deployments can be leveraged.

WPF however, has advantages out of the box for performance, but a smaller number of developers compared to JavaScript. In another blog, we explore whether WPF is dead (it’s not!) and the performance capabilities of JavaScript.

Accessing through hand-held devices is important for a field test engineer who may need a portable device that can sync with a JavaScript version of the oil and gas data dashboards.

It can be complicated to choose which one is right—there are performance benefits to using WPF, but JavaScript is more flexible and versatile. However, both are viable with the correct data visualization solution.

Data Visualizations for Wellsites

The data visualizations for wellsites outlined in this guide help decision-makers identify trends, anomalies, and insights that contribute to a healthy, safe, compliant, productive and profitable management of an oil or gas wellsite.

Time Series Charts

Time series charts show trends or numerical values over time. Line charts and strip charts, in particular, are commonly used to provide real-time insights and historical data analysis, making them invaluable for understanding changes in operational metrics and identifying patterns.

Line charts visualize changes in data over time, such as drilling depth, pressure, flow rates and temperature. Often in complex dashboards with multiple parameters, these are plotted on the same chart surface for comparative analysis, requiring annotations, overlays and trend lines.

Strip charts are used in real-time monitoring to display data trends in drilling rate or mud weight over time, with the ability to zoom and pan through time periods from extensive time-series data sets.

Wellbore Schematics

Wellbore schematics provide a visual representation of the downhole installation, including equipment and components, as well as tracking information on the history of the wellsite. These schematics track the history of the wellsite, providing a detailed overview of the well’s structure over time. By keeping accurate and up-to-date schematics, operators can easily reference past work and make informed decisions about future operations and maintenance work.

Vertical wellbore diagrams show casing strings, tubing and associated downhole equipment to see the well’s structure and completion design. With the inclusion of DAS and DTS, these diagrams can display real-time data or include other customized overlays.

Deviation plots show the deviation of the wellbore from vertical and are used in direction drilling and dashboards alongside wellbore diagrams. This data visualization offers a complete view of the well’s orientation and structure.

This combination of tools helps operators avoid potential hazards, reach target formations more efficiently, and optimize the drilling process.

3D Wellbore and Reservation Models

3D wellbore and reservoir models show the well path, geological formations and surrounding area, including porosity, permeability, fluid saturations and other properties. Typically, this includes Isosurfaces with 3D contours to represent various properties, e.g., specific pressure or saturation level, color coding or further overlaid data depending on requirements.

Geological and Geophysical Visualizations

Modelling geologic structures and formations helps decision-makers better understand the subsurface environment, improve drilling accuracy, and maximize the potential of both current and future wellbores.

Accurate log plots are designed to align drilling operations with the geological reality of the site. Displaying geophysical data along the depth of the well, resistivity, gamma ray, and porosity logs are shown side by side, allowing operators to identify distinct formation layers and fluid contacts.

This type of visualization helps interpret the rock and fluid properties of the subsurface, supporting decision-makers with their strategic placement of wellbore sections, casing points, and production intervals.

Mapped through seismic data, cross-sections display two-dimensional slices of the subsurface, which show faults, well paths, and other structural features. They help decision-makers and engineers understand the spatial relationship between various geologic features and the wellbore.

These visualizations support the planning process for directional drilling, ensuring that well trajectories avoid problematic areas, such as fault zones. Not just a way to avoid problematic areas, it can also make targeting productive formations easier, supporting profitable oil and gas exploration.

Mapping and Spatial Analysis

If you want to optimize extraction and delivery processes at your wellsite, mapping and spatial analysis charts could be one way to achieve that. This includes heat maps and contour maps. By better understanding spatial relationships between geological features and environmental conditions, decision-makers can make informed choices about factors such as the placement of the well.

Heat maps show the distribution of temperature, pressure or production rates across a wellsite or reservoir. Operators can quickly identify high or low-performing areas and make operational adjustments to enhance productivity. For instance, a heat map illustrating pressure changes can help pinpoint regions where additional interventions may be needed to maintain optimal extraction rates.

Contour maps feature contoured lines that indicate areas of equal values. By plotting contour lines, these maps enable operators to visualize gradients and identify trends across a site. The data visualization can illustrate geological areas of equal pressure, elevation, or thickness. This information is invaluable for understanding the subsurface geology, planning well trajectories, and making adjustments to drilling techniques.

Production and Performance Charts

Initial production (IP) and cumulative production rank well performance data and offer comparisons to predict future reserve output. By analyzing IP and cumulative production, decision-makers can make informed choices about resource allocation, drilling priorities, and long-term field development.

Production decline curves show production rates over time to estimate reserve production. Meanwhile, performance plots compare actual production of drilling against targets or models to highlight deviation and opportunity for optimization.

Safety and Environmental Monitoring

Safety and environmental monitoring provides metrics and alerts relating to emissions and health and safety incidents. Collectively, these charts enable proactive management of safety risks and environmental concerns, which are key to maintaining regulatory compliance and avoiding costly incidents.

But what options are available?

Alarm histograms help identify patterns in safety incidents and overlay into other analysis. They visually represent the frequency and timing of incidents, helping operators pinpoint recurring issues or areas of concern.

Meanwhile, environmental monitoring dashboards provide real-time display of emission data and spills, with alerts for compliance. Alerts for regulatory breaches, such as exceeding allowable emissions levels, facilitate prompt corrective actions to prevent environmental harm and potential legal penalties.

Statistical Visualizations

Statistical visualizations make data more palatable and actionable. Insights collected can be more easily communicated with stakeholders and decision-makers to help showcase areas for improvement.

Histograms and bar charts show the distribution of data, such as frequency of pressure ranges or rate-of-penetration (ROP) values. Understanding the distribution of parameters like pressure can be critical for ensuring the wellbore’s structural integrity. For example, a histogram can be used to display the frequency of different pressure levels encountered during drilling, which can help identify potential challenges or anomalies.

Scatter plots visualize relationships between different variables. As an example, a scatter plot of ROP vs. pressure could reveal that drilling speeds are lower at higher pressures, suggesting that adjustments to the drilling fluid composition or bit type might be necessary to maintain optimal performance.

Interactive Data Exploration Tools

Digital twins and multivariate analysis tools to explore relationships between multiple variables simultaneously or compare virtual models of the same wellsite.

Interactive dashboards cater to multiple stakeholders, often onsite and remote, interactive dashboard visualizations are compiled to get real-time and in-review analysis. Software UIs need to permit manipulation of chart surfaces, legends, tooltips, on-click behaviour and selective synchronization across surfaces.

Vertical wellsite depictions require synchronized and asynchronized zooming and panning on toggle, while all data needs to be monitored carefully, without failure due to data rates, and with precision to enable real-time decision-making in a safety-critical setting.

Create All These and More with SciChart’s Cross-Platform Charting Software

The benefits of choosing high-performance, big data software from SciChart is that you can build out across WPF, mobile android and JavaScript as it’s cross-platform compatible.

Other charting solutions struggle to support the big data requirements in the scientific niches. Using standard tools will make you the same as everyone else on the market. To unlock new metrics and overlays that contribute to enhanced profitability, you need the customisation levels that SciChart has to offer with their oil and gas data dashboards.

WPF vs. JavaScript: Which Is Best for Your Charting Project?

Andrew Bt — Tue, 24 Jun 2025 14:29:44 +0000

Windows Presentation Foundation (WPF) and JavaScript (JS) are popular framework and language options for developing client applications with user interfaces, but they offer distinct advantages and limitations that can impact your decision-making process. Choosing the right technology for your new data visualization or charting project can make a significant difference in both the development process and the final product’s performance.

If the buck stops with you on deciding whether to use WPF or JavaScript, you’ll want to feel confident in your choice and justify it to the team and stakeholders. You’ll want to know what the wider community thinks, while separating the myths from the facts. Even better, it would help if you had access to data and case studies to demonstrate the effectiveness of one framework over the other.

Ultimately, you want to say a project generated optimum results, and savvy research and decisions from the offset can help make that happen. This guide is one piece of the giant jigsaw puzzle of getting your data to work for your organization in the most efficient way possible. While JavaScript is taking a bold stand as a popular language to build impressive dashboards of charts, we’re looking at why WPF can be more powerful than JavaScript, particularly in high-performance, data-intensive applications, and where JavaScript may fall short.

There are some rumours in the technical community that WPF may be phased out, but this is far from true, and we covered this in detail in our article: Is WPF Dead? In fact, it’s estimated that there are around one million actively developed WPF applications worldwide, suggesting that WPF isn’t going anywhere anytime soon.

Support Ecosystem and Documentation

When choosing a development framework, your developers want access to comprehensive documentation, examples, and support. WPF, a mature and well-established framework, boasts an extensive collection of resources.

Microsoft’s official documentation, along with community-driven platforms like GitHub and Stack Overflow, provides developers with numerous reference points and practical insights. However, for the most up-to-date, comprehensive and easily accessible documentation, that’s where partnering with experts in WPF charts makes all the difference. It’s about getting the right support for your project to ensure your team members are aligned and up-to-speed with the best practices that get results.

SciChart’s leading WPF charting library also offers extensive technical support, training materials and documentation. And yes, we ease the onboarding process for new team members! We offer hundreds of code examples, thousands of forum questions, and hundreds of documentation, including tutorials on how to add annotations, cursors, and code for building chart series.

In contrast, JavaScript, particularly when used with open-source chart libraries, may lack this level of support. While there is a large community of JavaScript developers, the quality and consistency of documentation can vary significantly, potentially leading to longer development times and higher costs due to the need for additional troubleshooting and support.

Check out our series of articles on alternatives to popular JavaScript Chart libraries, which highlight the pros and cons of open source data visualization, such as Chart.js and D3.js.

Good documentation is only one consideration among many as to why you’d choose WPF over JavaScript, which we explore in the remainder of this article.

Performance Considerations

Performance is a key differentiator between WPF and JavaScript applications. This is particularly true for applications that require extreme performance and efficient data handling. But which one comes out on top for performance, and why?

As a native desktop framework, WPF offers unparalleled advantages:

It allows direct access to low-level hardware acceleration, such as GPU (graphics processing unit) via DirectX, and vectorization, which are crucial for rendering complex visualizations quickly and efficiently. Meanwhile, JavaScript has some access to the GPU via WebGL but no direct hardware access, introducing some overhead compared to desktop applications such as WPF.
WPF applications allow 64-bit memory addressing, allowing them to handle large volumes of data with minimal overhead, making them ideal for data-intensive tasks, such as real-time stock market applications or scientific simulations. In comparison, JavaScript has a limit of 4GB in the Chrome browser, and memory may be limited to 2GB for your client applications.
Multi-threading and use of multiple CPU cores (parallel processing) can only be done in desktop applications, such as WPF, as JavaScript applications are typically limited to a single thread.
On the other hand, JavaScript, despite its versatility and widespread use in web applications, faces inherent limitations due to the browser environment. The data transfer bottlenecks and rendering constraints within a browser can significantly impact performance, especially for applications requiring high-speed data processing. While memory limits are core issues, SciChart offers workarounds for these, no matter which supported framework or language you choose for your application.

While JavaScript frameworks can be optimized to some extent, they often cannot match the efficiency and speed of native WPF applications. For example, real-time F1 Pit Strategy Management software built with JavaScript can experience lag or slower data processing, whereas, a WPF-based platform can handle the data throughput more effectively. In fact, to talk numbers, WPF can render tens of billions of data points with ease, compared to tens of millions for JavaScript. 10 million is still impressive, but simply doesn’t quite live up to the data possibilities that WPF has to offer.

WPF is ideal for building complex, high-performance desktop applications that require close integration with the underlying operating system and hardware. Industries such as medical imaging, financial modeling, and scientific simulations benefit from WPF’s ability to utilize low-level routines for optimal CPU, GPU, and disk performance. Limited by the browser sandbox, JavaScript cannot provide the same level of control or efficiency.

Developer Resources and Long-Term Costs

If you’re a product owner or team lead, the availability and cost of developer resources may well sway your decision when choosing between WPF and JavaScript.

JavaScript developers are more abundant and cheaper to hire, and for that reason it may be a better choice. However, some projects can only be done with WPF, including those with the highest performance needs. WPF also provides more rapid prototyping due to its simpler Microsoft technology stack, especially if you have in-house engineers with C# experience.

Developing complex, high-performance applications in JavaScript can require more time and resources, leading to higher long-term costs. Additionally, the learning curve for transitioning between technologies should not be underestimated.

WPF developers can leverage the extensive documentation and support ecosystem to maintain and expand applications more efficiently, potentially leading to better long-term outcomes. It’s fast and easy. In fact, it’s possible to create a WPF chart with a clickonce installer, compared to JS which comes with a mountain of tech stack and proficient knowledge in React, Typescript, HTML, and much more. That takes years of training, and developers with this skill set are likely to charge more (and we’re not blaming them). But it’s something to bear in mind.

Conversely, hiring a seasoned JavaScript developer and training them on WPF might yield better long-term results than continuously dealing with JavaScript’s performance limitations.

This approach not only ensures the application meets performance expectations, but also reduces the need for constant troubleshooting and optimization, which can be both time-consuming and costly.

Remote Possibilities

WPF previously needed to be processed through a desktop application, a potentially restrictive way to visualize data. After all, the modern world of work often requires remote access to information through a portable device—something that JavaScript seamlessly enables. A field test engineer, for instance, may want to sync the content to a portable device. However, with the advent of Avalonia XPF and Scichart’s support for this, WPF apps are now cross-platform. This means a WPF app can be developed for Windows and Linux.

If you require native performance, 64-bit memory, or multi-threading, WPF is typically recommended over JavaScript.

That being said, with the right software provider and pre-processing data planning, you can port WPF charts into JavaScript. SciChart is a cross-platform solution that lets you work with the optimum charting language for each specific application you require it for. We’ve made SciChart for JavaScript charting as optimal as possible, using WebGL and WebAssembly to get near desktop performance levels. This allows our users to create medical devices, measure rocket telemetry, or even manage Formula One cars using JavaScript dashboards. Between 2011 and 2020, we increased our WPF chart controls from 20,000 data points to 10 billion data points, significantly improving the possibilities for our users. Likewise, our JavaScript chart controls reach millions of data points without slowdown.

So What Is the Verdict?

We’ve offered our insights, but it’s important to weigh up the strengths and weaknesses of WPF and JavaScript for yourself.

WPF offers a robust support ecosystem, superior performance capabilities, and long-term cost-effectiveness, making it an ideal choice for high-performance, data-intensive applications.

In contrast, while JavaScript may seem more accessible due to its widespread use and lower initial costs, it may fall short in delivering the performance and efficiency required for complex applications.

Ultimately, the decision should be based on a comprehensive understanding of your project’s specific needs and the technological capabilities of each framework. By carefully considering these factors, you can make an informed choice that aligns with your project’s goals and ensures long-term success.

Reluctant to commit to a single solution for your data visualization projects? SciChart offers both WPF and JavaScript charts, and we are the only native cross-platform library that works across WPF, JavaScript, iOS, and Android.

Showcase of the Best WPF Charts and Graphs Demos

Andrew Bt — Tue, 24 Jun 2025 14:25:07 +0000

WPF Charts are indispensable for visualizing and interacting with big data sets, especially in industries where performance, precision, and customization are critical. The WPF framework is a preferred choice for developing bespoke, complex applications in engineering, scientific research, medical fields, and other domains requiring high-performance data visualizations.

A well-designed WPF Chart Library does more than display data—it empowers developers to create dynamic, intuitive dashboards in C# .NET and MVVM, tailored to handle the complexities of real-time analytics and actionable insights. These libraries enable the development of custom solutions, perfect for meeting the unique demands of specialized applications.

Whether you’re monitoring financial markets, monitoring patient health, managing industrial operations, or building dashboards for power stations, WPF Charts offer the flexibility and power needed to bring intricate data to life. Their combination of performance, adaptability, and ease of use makes them the go-to choice for professionals tackling complex, data-heavy challenges.

In this guide, we explore the best WPF Charts and Graphs that stand out in the realm of .NET development, demonstrating how they can transform dense big data into captivating and informative visual narratives.

Explore our Advanced WPF Charts & Graphs Examples for Various Applications

Realtime WPF Audio/Spectrum Analyzer Demo

The Spectrogram Demo shows how to mix a 2D line chart showing a Fast Fourier Transform (FFI) of a waveform, and also show a spectrogram (scrolling heatmap) of the same data. The scrolling heatmap is achieved using a SciChartSurface with a FastHeatMapRenderableSeries and by updating the data on a Heatmap2DArrayData Series. The result is a smooth 30FPS scrolling heatmap, allowing you to visually inspect your spectrum data.

Big-Data 1-Billion Datapoint WPF Chart Demo

Fifo 1 Billion Points Demo

Our 1 billion points demo showcases the incredible performance when rendering streaming (scrolling) line charts. It showcases that SciChart is capable of rendering 1 billion (1,000,000,000) points in real-time at 60 fps.

From real-time monitoring to visualizing the output of telemetry sensors, this chart renders huge data sets with speed and precision. Leveraging the FIFO series, the chart automatically discards old data points once a predefined number of points is met. This type of data series is extremely efficient for scrolling charts, where you do not care about discarded (off-screen) data.

This demo is possible due to our newly introduced Visual Xccelerator(TM) engine, a completely in-house, proprietary, cross-platform C++ game engine, fully GPU-accelerated using pixel and vertex shaders, which we’ve built layers on top of to create 2D/D charts. With the SciChart WPF Xccelerated Edition, you can achieve up to 100x Faster WPF Charts.

Digital Logic Analyzer Demo

Digital Logic Analyzer in WPF - big data charts, high performance with interactive zooming, panning and scrolling

The WPF Digital Logic Analyzer Demo captures and displays multiple signals from a piece of hardware, such as a Data Acquisition Card or Logic Analyzer.

In the above example, you can see multiple channels with randomly generated binary data with a common XAxis. It is implemented using the MVVM pattern to display multi-surface pane rendering FastLineRenderableSeries that use UniformXyDataSeries as a data source.

Requiring Y-Values only, this DataSeries type reduces memory consumption.

With all this in mind, it is possible to display tens of billions of points on a single view. This specific demo loads up to 64 billion data points with 64GB RAM. 100 billion data points are also possible with 128GB of RAM.

ChartModifiers also provide interactivity to create a more engaging chart experience. We support the following interactions, and much more besides:

[CTRL + MouseWheel] to scroll channels up and down
[SHIFT + MouseWheel] to change the height of channels
[Mousewheel) to zoom channels data in and out

Vital Signs ECG/EKG Patient Monitor Demo

In this WPF vital signs ECG/EKG monitor demo, you can see how the Line Series is used to draw real-time FIFO data for use in a medical context. The example simulates four channels that enable health professionals to monitor heart rate, body temperature, blood pressure, pulse, SP02 blood oxygen and volumetric flow simultaneously in one real-time ECG/EKG data visualization.

SciChart provides the shortcuts your development team needs, providing rich, real-time, high performance and reliable charts for medical and healthcare applications. There is also the Scatter Series used for a single point at the beginning of the lines. The fading effect is achieved with the Palette Provider API.

Building WPF Charts with MVVM

If you want to improve code reuse opportunities across your application and create a clean distinction between your user interface and application logic, you may prefer to build your WPF charts with MVVM. SciChart has specific demos for this, including examples of how to bind multiple charts and add a zoom history function.

The above demo demonstrates how to undo/redo Zoom and Pan (Zoom History) by using the ZoomHistoryManager type in an MVM application. The ZoomHistoryManager is attached to the chart via the SciChartSurface.Z.comHistoryManager property.

All zoom and pan operations then become tracked, and you can undo or redo the zoom function via the ZoomHistoryManager.Undo and ZoomHistoryManager.Redo methods.

In MVM applications, you can also bind to and execute the ZoomHistoryManager.UndoCommand and ZoomHistoryManager.RedoCommand.

WPF Chart Types

With 35 2D and 15 3D WPF charts, SciChart doesn’t just support out-of-the-box graphs but also enables endless customizations so you can visualize large data sets however you want.

A WPF animation API and interactive chart applications let you create engaging visuals that help the end user glean the information they require. It’s all about making data accessible and visually appealing without draining your development resources.

SciChart’s easy-to-use interface and guides ensure developers have all the tools they need to get started and produce the best WPF charts and graphs quickly and efficiently. We have hundreds of forums and documentation to help developers of any level build the best WPF charts and graphs with ease.

You’ll also have access to a theme manager for styling changes and a powerful annotations API, helping you present data in the most effective way for your business, stakeholders, and end users.

Who Uses SciChart?

SciChart’s fully customizable WPF Charts are used by investment banks, space agencies, top Formula 1 teams and companies in the tech, medical, engineering, electrical, and oil and gas domains. As you can see from the showcase above, we support a diverse range of customized features to help your users get the most out of their data.

Showcase of the Best React Charts and Graphs

Andrew Bt — Tue, 24 Jun 2025 14:14:58 +0000

Liquid syntax error: Unknown tag 'endembed'

Showcase of the Best React Charts and Graphs

Andrew Bt — Mon, 31 Mar 2025 11:00:12 +0000

React Charts are revolutionizing the way we visualize and interact with complex data. These charts are not just tools for displaying information; they are gateways to deeper insights and analytics. React’s robust framework, combined with advanced charting libraries, empowers developers to build intuitive and responsive dashboards that can handle the complexities of real-time analytics & data visualization.

Whether you’re monitoring financial markets, analyzing health data, or tracking sports statistics, React Charts bring data to life. Their versatility and performance cater to a broad spectrum of industries, enabling users to dissect and comprehend intricate datasets with ease. In this guide, we explore the best React Charts and Graphs that stand out in the realm of web development, demonstrating how they can transform dense data into captivating and informative visual narratives.

Join us as we explore the realm of React Charts. Here, every graph and chart is more than just a visual representation; it’s an essential tool for insightful data analysis, unlocking the full potential of your datasets in clear and compelling ways.

Explore our Advanced React Charts & Graphs Examples for Various Applications

Realtime Updates in React Charts

React Charts can be used to display data in dashboards, analytics applications and more. However some applications require real-time updates and high performance to ensure data which is dynamically changing can be visualized fast.

Real-time React Chart Performance Demo

Demonstrates appending millions of points to a react line chart. Dynamic data updates previously have been a performance problem in React applications but with this demo 300k points per second are added to the chart. Millions of datapoints can be rendered in React Charts with scichart.js without performance problems!

Realtime React Chart Performance Demo

React Big-Data Dashboard demo

Dashboards with tens, hundreds of charts and millions of datapoints were previously impossible in React. In this performance demo we show how you can have 64-charts all updating at once, with millions of points streaming dynamically in real-time.

React Dashboard Big-Data Performance Demo

React Financial Charts

Financial charts in react could include stock charts, price charts, trading charts with technical indicators. Charts for React Trading applications need to be highly interactive, show cursors, legends and tooltips, allow zooming and panning, as well as updating data in real-time.

Some examples are included below.

React Stock Chart with Technical Indicators

In this demo we show how to create a React Stock Chart with technical indicators. MACD and RSI indicator are added onto separate chart panes. Moving averages are added onto the main pane. There is an active legend and crosshair which tracks the mouse. The entire example can be zoomed or panned via touch or mouse interactions.

React Multi-Pane Stock Charts Example

Realtime Stock Charts in React

Connecting a React Candlestick Chart to financial data in an exchange is easy. In this example, price data is fetched from an exchange via REST API, then dynamically updated using a WebSocket. Candlestick charts are updated on price tick. Technical indicators (moving average) are calculated, and the chart allows zooming, panning to view older data.

JavaScript Realtime Ticking Stock Charts

Medical & Scientific Charts in React

Medical applications are more and more being ported to React. Before, they were often C++ or C# applications. Medical device & medical software manufacturers expect high performance, reliability and low memory usage in charts & graphs. A showcase of examples can be found below.

Visualising Cardiac Telemetry: ECG/EKG Heart Rate Monitors in React

Plotting a sweeping medical ECG is easy in React with this software. Cardiac telemetry often needs to be visualised on medical devices or patient monitoring systems. Data traces can be cardiac telemetry, heart rate, blood oxygen, SPO2, blood pressure are plotted to the right of the graph, then wrap around to the beginning. This is possible with SciChart.js’ Fifo Sweeping Mode.

JavaScript Vital Signs ECG/EKG Medical Demo

Creating Echocardiograms, Ultrasound & Sonar in React

Echocardiograms, Ultrasound, Sonar, Thermal imaging and more can be created in React. Using a dynamic heatmap chart type

React Heatmap / Spectrogram Chart Demo

React Chart Types

It’s not just complex financial & medical charts that can bring a new lease of life to your data visualizations. Variations in React Line Chart include a wide range of different line styles, such as simple lines, digital lines, tooltips, dashes, gaps, labels, hovering lines and more.

React Donut Chart

React Pie Chart

React Stacked Area or Stacked Mountain Chart

React Stacked Bar or Stacked Column Chart

React 3D Bubble Chart

React Line Charts

Who Uses SciChart?

SciChart’s fully customizable React Charts are used by investment banks, NASA, top Formula 1 teams and companies in the tech, medical, engineering, electrical, and oil and gas domains. As you can see from the showcase above, we support a diverse range of customized features to help your users get the most out of their data.

What is React Strict Mode, and why is my Application Double Re-Rendering?

Andrew Bt — Mon, 31 Mar 2025 10:24:58 +0000

React StrictMode is a development tool intended for producing hints about potential issues in React applications. With the release of React v18, Strict Mode was extended with a new feature which brought some unusual behaviour. Specifically, implicitly calling the rendering related functions extra times.
While this feature is useful for finding bugs, the unexpected flow it introduced compared to the normal React lifecycle may be redundant and requires extra effort to deal with in some applications.
In this article we explore what is React StrictMode, why this causes your application to double re-render, and how this impacts performance and memory when rendering charts in React apps. Finally, how to solve the problem by applying additional logic to handle strict mode.

What is Strict Mode in React?

React StrictMode applies a set of behaviours and warnings that can help spotting different kinds of React related bugs. The list includes incorrect logic of the lifecycle methods (e.g. missing cleanup logic) and usage of the deprecated APIs.

StrictMode can be enabled by wrapping a whole component tree or a part of it with component:

import { StrictMode } from "react";

// ...

<StrictMode>
  <App />
</StrictMode>

The component doesn’t add any UI elements to the render result and doesn’t affect the production build as this is a development-only. React-based frameworks can expose a config option to toggle the StrictMode on and off, so it is worth to be aware if it is enabled by default.

What Happens in Strict Mode?

To help detecting a missing state reset or cleanup, React StrictMode executes extra calls of a render function as well as effect hooks. Extra execution of effects happens only upon an initial render, while the component function is always called twice.

The behaviour effect is similar for different arguments provided as an effect hook dependencies list. The most confusing and error-prone case is when a hook is expected to run only once. So let’s look at a component that has an effect hook with an empty dependencies list.

function TestComponent() {
  console.log("Rendering TestComponent");

  useEffect(() => {
    console.log("Executing Effect");

    return () => {
      console.log("Executing Effect Destructor");
    };
  }, []);

  return (
    <div className="App">
      <h1>Random generated number</h1>
      <h2>{Math.random()}</h2>
    </div>
  );
}

We will create a simple setup which allows us to render a component and then unmount it using a conditional rendering.

As expected during normal rendering we would get a following console output:

Rendering TestComponent
Executing Effect
Executing Effect Destructor // - appears after the component is unmounted

With StrictMode on:

Rendering TestComponent
Rendering TestComponent
Executing Effect
Executing Effect Destructor
Executing Effect
Executing Effect Destructor // - appears after the component is unmounted

As you can see useEffect is executed twice when StrictMode is enabled, and the cleanup function (or destructor) is also executed twice. This can cause unwanted effects, or performance problems if useEffect has a lot of code to execute, or if the cleanup function is not implemented properly.

Why Strict Mode is useful

So what do we get from this behaviour:

Calling the component twice could uncover potential issues of side effects that may occur within the render function.
Calling the effect and effect destructor twice guarantees that the destructor will run at least once, so the cleanup logic will be tested immediately. So as result of these, an error is more likely to happen and thus more likely to be discovered during development. Usually these problems are caused by breaking the Rules of React.

Why Strict Mode may cause problems

Depending on the logic and structure of an application side effects and their cleanup could be implemented differently.

In some cases it may be harder to implement logic that would handle Strict Mode gracefully
Sometimes code that is breaking in Strict Mode could be still safely executed in production.
Enabling Strict Mode could make the app execution different from what it would be in production.
This could greatly affect the performance of the application as well.

The complexity of handling the cleanup logic becomes even more difficult in combination with asynchronous code.

Handling React StrictMode Correctly

Obviously if Strict Mode interrupts your development process a lot or you just don’t want to use it, you can always turn it off. The affected area of an application could be limited to specific component tree area.

But if that is not viable option or you need to create a sharable component that works properly with or without StrictMode, than you have to build the component accordingly to the Rules of React.

Preventing useEffect from running twice on mount

There are techniques that allow handling the double useEffect execution in StrictMode by conditionally preventing the effect logic execution in one of the calls. Be aware that they aren’t something you should use.

Let’s assume we have heavy computation logic that we don’t wont to be executed more than once when a component renders. Also the execution of such logic may create side effects which require cleanup.

const performSideEffectLogic = () => {
  console.log("Perform Side Effect");
};

const cleanupSideEffectResult = () => {
  console.log("Cleanup Side Effect Result");
};

function TestComponent() {
  console.log("Rendering TestComponent");

  useEffect(() => {
    console.log("Executing Effect");
    performSideEffectLogic();

    return () => {
      console.log("Executing Effect Destructor");
      cleanupSideEffectResult();
    };
  }, []);

  return (
    <div className="App">
      <h1>Random generated number</h1>
      <h2>{Math.random()}</h2>
    </div>
  );
}

If we want to just ignore the double execution of the effect and call performSideEffectLogic only once, we can add a flag to our component state that will identify if the effect has already been executed.
Since the second execution of the effect with empty dependencies list in same instance component would normally run only once, if it does otherwise we can treat it as being in Strict Mode.

const effectWasExecuted = useRef(false);

const [data, setData] = useState<number>(undefined);

useEffect(() => {
  console.log("Executing Effect");
  if (effectWasExecuted.current) {
    performSideEffectLogic();
  }

  const cleanup = () => {
    console.log("Cleanup");
    setData;
  };

  return () => {
    console.log("Executing Effect Destructor");

    if (process.env.NODE_ENV !== "production" && effectWasExecuted.current) {
      cleanupSideEffectResult();
    }
    effectWasExecuted.current = true;
  };
}, []);

Note that this is an easy workaround, but definitely not a recommended approach. Also StrictMode behaviour is related to the new features that may appear in React and this trick is likely to no longer work in the future releases.

The correct approach is to build logic the way it would handle the double effect execution.

How React Strict Mode Affects JavaScript Charts

When developing applications in React, it is critical it is to understand the proper lifecycle of a React component. This is amplified when an application uses heavy performance and memory operations.

The SciChart.js library is designed to be a high performance chart for use in data-intensive applications, and setup and cleanup of big-data charts needs to be made as efficient as possible. The performance metrics of SciChart.js are profiled often, and the documentation has many tips on how to use the library optimally for best performance in your application.

However, Strict Mode can cause double re-render which means setup and teardown logic of the charts can occur twice, impacting performance in development mode and even causing ‘false positive’ memory leaks.

Testing with a disabled Strict Mode is important as well as testing the production build, and ensuring that you adjust your application to handle and deal with double re-render.

How Double Re-Render Affects SciChart

SciChart.js is a high performance JavaScript Chart library that requires a few setup prerequisites.

First of all it loads a WebAssembly modules. This may require a network request and compilation execution. Both are asynchronous operations.

Then a chart could be created via an asynchronous function. A chart instance is an entity that requires an explicit cleanup by calling the sciChartSurface.delete() function. In addition to that SciChart creates DOM elements on a page.

This presents a tricky problem of embedding the logic into a component lifecycle. Things become even more confusing when the StrictMode behaviour takes effect.

How we solved the problem of StrictMode with SciChart-React

SciChart-React is an open source library which applies additional logic to handle both normal flow and strict mode when using SciChart.js High Performance React Charts.

It doesn’t prevent the double execution of lifecycle methods. To handle async function execution we chain the deletion to to the init promise. Also we track if the component is mounted and check if the destructor was called. It is also important to set the state accordingly.

Here’s an extract from scichart-react SciChart.tsx file showing how we do this:

useEffect(() => {
        // generate guid to distinguish between effect calls in StrictMode
        const chartId = generateGuid();
        groupContext?.addChartToGroup(chartId, false, null);

        const rootElement = innerContainerRef.current;
        rootElement!.appendChild(chartRoot as Node);

        const initializationFunction = initChart
            ? initChart
            : (createChartFromConfig<TSurface>(config) as TInitFunction<TSurface, TInitResult>);

        let cancelled = false;

        const runInit = async (): Promise<TInitResult> =>
            initializationFunction(chartRoot as HTMLDivElement).then(result => {
                if (!result.sciChartSurface) {
                    throw new Error(wrongInitResultMessage);
                }
                // check if the component was unmounted before init finished
                if (isMountedRef.current && chartRoot) {
                    groupContext?.addChartToGroup(chartId, true, result);
                    initResultRef.current = result;
                    setIsInitialized(true);

                    if (onInit) {
                        cleanupCallbackRef.current = onInit(result);
                    }
                } else {
                    cancelled = true;
                }

                return result;
            });

        // workaround to handle StrictMode
        const initPromise = initPromiseRef.current ? initPromiseRef.current.then(runInit) : runInit();
        initPromiseRef.current = initPromise;

        const performCleanup = (initResult: TInitResult) => {
            if (!cancelled && cleanupCallbackRef.current) {
                cleanupCallbackRef.current();
                cleanupCallbackRef.current = undefined;
            }

            if (!cancelled && onDelete) {
                onDelete(initResult);
            }

            initResultRef.current = null;
            setIsInitialized(false);

            groupContext?.removeChartFromGroup(chartId);
            initResult.sciChartSurface!.delete();
        };

        return () => {
            // wait for init to finish before deleting it
            initPromise.then(performCleanup);
        };
    }, []);

    const groupContext = useContext(SciChartGroupContext);

    return (
        <!-- DOM elements omitted for brevity ->
    );

Using code like this we’re able to handle the asynchronous creation of SciChart.js charts and the proper cleanup, whether the application is run in strict mode or not. Extra handling around asynchronous calls is required to ensure that cleanup code is executed once only, and always when the component is unmounted.

Conclusion: Should you use React StrictMode?

We believe you should. Strict Mode will help you by reminding about proper component lifecycle handling and will emphasize the potential issues. Thus, it is worth using it.

However,

it is important to be aware whether an application has the mode enabled.
Application testing should better be performed both with the mode enabled and disabled.
You must ensure that you correctly handle useEffect cleanup, especially when initialization of a component has asynchronous code

How to change the dash, stroke or point style of a specific section of a line chart in JavaScript

Andrew Bt — Mon, 31 Mar 2025 10:05:41 +0000

In this blog post will cover how to change the style of a specific part of a line, scatter, column or mountain chart in JavaScript.

Perhaps you want to create a JavaScript Line Chart where part of the line is dashed and part is solid.

Or perhaps a JavaScript scatter chart where different point-markers (e.g. circle, cross, triangle, square) are displayed on different parts of the chart series.

Above: React Chart with Multi Series Style example, showing how to dynamically switch styles in a javascript/react chart

This could be an important use-case in real-time analytics, where you want to show additional states on a JavaScript chart, for example, data with low confidence could be displayed as a dashed line or semi-transparent line, whereas data with high confidence could be displayed as a solid line.

Solution 1 – Multiple Series

Until now, various JavaScript chart libraries can only achieve changing the style of a line chart dynamically using multiple series.

For example, in order to achieve a JavaScript line chart where different segments are dashed and solid, you would need to have two separate line series on the same 2D chart.

Many chart libraries such as chart.js will allow you to display a line chart with both solid and dashed line by using this technique, for example having two datasets with two different styles on the same chart (see StackOverflow: Can we draw a line chart with both solid and dotted line in it).

var lineChartData = {
    labels: ['A', 'B', 'C', 'D', 'E', 'F', 'G'],
    datasets: [{
        label: "My First dataset",
        data: [1, 8, 3, 4, 2, 3, 4],
        borderColor: '#66f',
        borderDash: [20, 30]
    },{
        label: "My First dataset",
        data: [1, 8, 3, 4, 2, , ],
        borderColor: '#66f',
    }]
};

var ctx = document.getElementById("chart").getContext("2d");
var myChart = new Chart(ctx, {
    type: "line",
    data: lineChartData,
    options: {
        elements: {
            line: {
                fill: false
            }
        }
    }
});

This results in the following output (JSFiddle: https://jsfiddle.net/uwb8357r)

Apache eCharts also has a similar way of handling splitting of series of different styles. For example, this stackoverflow post titled How to Change the style of a specific section/part of a line to dotted/dashed describes how you can change the style of a specific section/part of a line chart to dotted/dashed lines in eCharts, and the only solution is to have two series, one for each line. One for solid line, one for dashed line, with two separate datasets.

This is not a bad solution, however in the case where you have multiple series on a chart, or where you have a legend, or want to handle selection / clicking / hovering callbacks or drilldowns on a chart, having extra series present in the data model can confuse your software developers by making the code more complex than it needs to be and more difficult to understand or maintain.

It would be a better solution to have a single line series with multiple styles applied to the same series. However, how can this be done in JavaScript?

Solution 2 – Using the Render Data Transform API in SciChart.js

SciChart.js – a High Performance JavaScript and React Chart library for scientific, engineering, medical and financial applications features an API called Render Data Transforms.

This API allows you to transform your data immediately before it is drawn, affecting the final visual output on the screen while keeping your data unchanged.

It also allows you to perform visual transformations in a JavaScript chart, for example:

Interpolating data to insert extra points (spline, Bezier transformation)
Switching styles on a series, for example having dashed/solid lines as part of the same line chart
Splitting line segments, for example inserting extra points to deal with color-transitions at thresholds where a line goes above/below a threshold value One such use-case of the RenderDataTransforms API would be to allow you to switch styles between solid and dashed lines in a JavaScript chart, using the same dataset & single series.

For this worked example we’ll use the same dataset as the chart.js example previousl provided, however with an additional third parameter called dash which is 0 or 1 (where 0 means solid line, 1 means dashed line).

X = [0,1,2,3,4,5,6]
Y = [1,8,3,4,2,3,4]
Dash = [0,0,0,0,1,1,1]

_It’s important to note that a 1 in the Dash[] array means this point has a dashed line, however a dashed line segment must be defined by two points. Therefore an array for dashes of [0,0,0,0,1,1,1] would actually result in two dashed segments at the end of the chart. _

In SciChart.js, X,Y data can be stored in a XyDataSeries, and additional information can be stored in a flexible JavaScript object called Metadata. To declare a data series with the above data, use this code:

// Create the data. X,Y values are numeric
// dashValues are mapped to metadata (javascript objects)
const xValues = [0,1,2,3,4,5,6];
const yValues = [1,8,3,4,2,3,4];
const metadata = [0,0,0,0,1,1,1].map(num => ({ dash: num }));

const dataSeries = new XyDataSeries(wasmContext, { xValues, yValues, metadata });

Next, we need to setup a chart which will render the data as a line series.

  // Create a SciChartSurface with X,Y Axis
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(divElementId, { 
    theme: new SciChartJsNavyTheme() }
  );
  sciChartSurface.xAxes.add(new NumericAxis(wasmContext));
  sciChartSurface.yAxes.add(new NumericAxis(wasmContext, { growBy: new NumberRange(0.1, 0.1)}));

  // Create the data. X,Y values are numeric
  // dashValues are mapped to metadata (javascript objects)
  const xValues = [0,1,2,3,4,5,6];
  const yValues = [1,8,3,4,2,3,4];
  const metadata = [0,0,0,0,1,1,1].map(num => ({ dash: num }));

  const dataSeries = new XyDataSeries(wasmContext, {
      xValues,
      yValues,
      metadata
    });  
  const lineSeries = new FastLineRenderableSeries(wasmContext, {
    dataSeries,
    strokeThickness: 3,
    stroke: "SteelBlue",
    pointMarker: new EllipsePointMarker(wasmContext, { width: 7, height: 7, strokeThickness:0, fill: "SteelBlue"})
  });

  sciChartSurface.renderableSeries.add(lineSeries);

To split the style in the series based on the metadata[i].dash value, we need to use a RenderDataTransform. We can also inject something called a DrawingProvider into the line series to draw the alternate points. Let’s setup this code below:

class DashedOrSolidRenderDataTransform extends XyyBaseRenderDataTransform {
  protected runTransformInternal(renderPassData: RenderPassData): IPointSeries {
  // Guard in case the incoming data is empty
  // If you want to do nothing and draw the original data, you don't need to copy it, you can just return renderPassData.pointSeries
  if (!renderPassData.pointSeries) {
    return this.pointSeries;
  }
  // It is important to reuse this.pointSeries.  Do NOT create a new pointSeries on each transform
  const {
    xValues: oldX,
    yValues: oldY,
    indexes: oldI,
    resampled,
  } = renderPassData.pointSeries;
  const { xValues, yValues, y1Values, indexes } = this.pointSeries;

  // Clear the target vectors
  xValues.clear();
  yValues.clear();
  y1Values.clear();
  indexes.clear();

  // indexRange tells the drawing to only use a subset of the data.  If data has been resampled, then always use all of it
  const iStart = resampled ? 0 : renderPassData.indexRange.min;
        const iEnd = resampled ? oldX.size() - 1 : renderPassData.indexRange?.max;
        const ds = this.parentSeries.dataSeries as XyDataSeries;
        let prevDash = false;
        for (let i = iStart; i <= iEnd; i++) {
            const index = resampled ? oldI.get(i) : i;
            const md = ds.getMetadataAt(index);
            xValues.push_back(oldX.get(i));
            indexes.push_back(oldI.get(i));
            // Add normal point if the current or previous is not dashed
            yValues.push_back((!md.dash || !prevDash) ? oldY.get(i) : NaN);   
            // Add dashed point if the current or previous is dashed
            y1Values.push_back(prevDash || md.dash ? oldY.get(i) : NaN);

            if (md.dash && !prevDash) {
              // Add a break in the normal if the current is dashed but the previous was not
              xValues.push_back(oldX.get(i));
              yValues.push_back(NaN);
              y1Values.push_back(oldY.get(i))
            } else if (!md.dash && prevDash) {
              // Add a break in the dashed if the current is not dashed but the previous was
              xValues.push_back(oldX.get(i));
              yValues.push_back(oldY.get(i));
              y1Values.push_back(NaN);
            }
            prevDash = md.dash;
        }
    // Return the transformed point series
        return this.pointSeries;
  }
}

The Render Data Transform must be applied to a series like this before the series is added to the chart:

// Add the new drawingProvider to the series. The selector ps.y1Values means use the alternate data provided by the render transform
const dashedDrawingProvider = new LineSeriesDrawingProvider(wasmContext, lineSeries, (ps) => ps.y1Values);
lineSeries.drawingProviders.push(dashedDrawingProvider);

dashedDrawingProvider.getProperties = (parentSeries) => {
 const { stroke, strokeThickness, opacity, isDigitalLine, lineType, drawNaNAs } = parentSeries;
 return {
     stroke,
     strokeThickness,
     strokeDashArray: [3, 4], // Here's where we swap out stroke-dashing
     isDigitalLine,
     lineType,
     drawNaNAs,
     containsNaN: true,        
  };          
};

// Create the transform and add it to the series. Pass only the lineDrawingProviders
lineSeries.renderDataTransform = new DashedOrSolidRenderDataTransform(lineSeries, wasmContext, [lineSeries.drawingProviders[0], dashedDrawingProvider]);

Here’s the output result:

Simplifying the Solution by Encapsulating Logic into a Custom Series

The solution provided relies on a lot of boilerplate code, which can be simplified greatly be encapsulating into a Custom Series.

One of the benefits of SciChart.js is that it’s an extremely extensible JavaScript Chart Library, meaning that you can write your own series types, extensions, interaction types or custom rendering in JavaScript, allowing you to infinitely configure the charts in your application to meet user requirements.

Here’s a class for a custom series called DashDottedLineSeries which is based on the FastLineRenderableSeries and the RenderDataTransforms API.

class DashDottedLineSeries extends FastLineRenderableSeries {
  constructor(wasmContext, options) {
    super(wasmContext, options);
    this.alternateStrokeDashArray = [3,4];
    this.alternateStroke = "Orange";

    // Add the new drawingProvider to the series
    const dashedDrawingProvider = new LineSeriesDrawingProvider(wasmContext, this, (ps) => ps.y1Values);
    this.drawingProviders.push(dashedDrawingProvider);

    dashedDrawingProvider.getProperties = (parentSeries) => {
      const { stroke, strokeThickness, opacity, isDigitalLine, lineType, drawNaNAs } = parentSeries;
      return {
          stroke: this.alternateStroke,
          strokeThickness,
          strokeDashArray: this.alternateStrokeDashArray,
          isDigitalLine,
          lineType,
          drawNaNAs,
          containsNaN: true,        
      };
    };

    // Create the transform and add it to the series. Pass only the lineDrawingProviders
    this.renderDataTransform = new DashedOrSolidRenderDataTransform(this, wasmContext, [this.drawingProviders[0], dashedDrawingProvider]);  
  }    
}

Now the usage comes down simply to this:

// Create a SciChartSurface with X,Y Axis
const { sciChartSurface, wasmContext } = await SciChartSurface.create(divElementId, { 
    theme: new SciChartJsNavyTheme() 
});
sciChartSurface.xAxes.add(new NumericAxis(wasmContext));
sciChartSurface.yAxes.add(new NumericAxis(wasmContext));

// Create the data. X,Y values are numeric
// dashValues are mapped to metadata (javascript objects)
const xValues = [0,1,2,3,4,5,6];
const yValues = [1,8,3,4,2,3,4];
const metadata = [0,0,0,0,0,1,1].map(num => ({ dash: num }));

const dataSeries = new XyDataSeries(wasmContext, {
  xValues,
  yValues,
  metadata
});  
const lineSeries = new DashDottedLineSeries(wasmContext, {
    dataSeries,
    strokeThickness: 3,
    stroke: "SteelBlue",
    pointMarker: new EllipsePointMarker(wasmContext, { width: 7, height: 7, strokeThickness:0, fill: "SteelBlue"})
});
sciChartSurface.renderableSeries.add(lineSeries);

Here’s the simplified output result:

Conclusion

In JavaScript or React it’s possible to create data-analytics applications where certain sections of a line chart are dotted/dashed while other sections are solid. It’s also possible to dynamically change the stroke color, stroke thickness, or pointmarker of a line chart in JavaScript for sections of the data with higher/lower confidence, or to signify events or areas of importance in the data.

This can be achieved in SciChart.js by using a Render Data Transforms API, which allows you to inject styles or extra data-points into a JavaScript chart immediately before draw.

Finally, to simplify your application code, logic for the Render Transform can be encapsulated into a custom series, which can then be re-used throughout your application.

React Charts with SciChart.js: Introducing scichart-react

Andrew Bt — Mon, 31 Mar 2025 09:23:01 +0000

TLDR: In this blog post we introduce a brand new open source library called scichart-react (npm, GitHub). This makes it easy to create stunning high-performance charts and data visualizations in React.

SciChart-React has now been released and is on npm as scichart-react. Examples, samples, documentation & tutorials are coming soon.

The official SciChart / React package solves the problem of component lifecycle with SciChart.js and avoids common pitfalls when creating charts in React. Code examples are given below of how to create React Charts, as well as where to find further information about this new React chart component.

Why Choose React JS for Chart Creation?

React JS has become the preferred choice for enterprises seeking robust and efficient application development, largely due to its component-based architecture, high performance, and rich ecosystem. Unlike other frameworks like Angular, React stands out for its virtual DOM, which ensures faster rendering and smooth handling of complex, data-intensive visualizations. Its modular nature allows for the creation of reusable, maintainable chart components, streamlining development and scalability. Additionally, React’s vast library of tools and strong community support offers a wealth of resources, making it more adaptable to various charting requirements. The combination of flexibility, efficient data handling, and cross-platform compatibility positions React as a dominant force in the realm of enterprise-level data visualization, outpacing competitors in terms of performance and versatility.

Why Choose SciChart.js for React Charts?

SciChart.js is an advanced react chart library for use in complex and advanced mission critical applications. SciChart’s key features include extremely high performance for big-data sets, a wide set of chart types, deep features and customisability.

For a full run-down of SciChart.js’ features and why you should consider it for enterprise apps with complex requirements, read the following post:
The Best JavaScript Chart Library: 10 Compelling Reasons to Choose SciChart.js in 2024

Create React Charts easily with SciChart-React

Earlier in the year, we published an article titled How to create a re-usable react component for SciChart.js. This demonstrated how to create charts in React by applying a few criteria for creation of a React Chart component:

The component should be reusable for different chart configurations
It should be possible to safely create several instances of the component
It should be easy to add custom functionality to the component
When chart instantiation is an async function, this should be properly handled
When the chart requires a root element in the DOM it should exist before chart instantiation
Finally, the chart should be properly disposed and memory deleted after the component is unmounted. As background reading it’s worth reading the article. Problems which occurred in the past when creating React Charts with SciChart.js included double re-render, and potential memory leaks if your code improperly disposed of a chart surface by failing to call .delete().

We’ve created a new library called scichart-react which is open sourced and available on Github and npm. This solves the problems above and ensures that you have good quality code managing your react components and provides a clean, neat way to instantiate charts in react using simple props.

Step-by-Step Guide: Building Your First Chart in React with SciChart.js

SciChartReact provides an easy solution for using the SciChart core library for charts in React.

In the next sections, we will demonstrate a basic usage of the component.

Basic React Chart Example

Follow the prerequisites and installation sections from https://www.npmjs.com/package/scichart-react.

And just with few lines of code, you can set up a chart in React.

Create a Chart with Config (Builder) API

The Builder API in SciChart allows you to create charts in JavaScript with JS objects or JSON. This can be translated into React using scichart-react as follows.

The example uses the config property which accepts a configuration object of the chart. You can also pass a string with serialized chart configuration.
import { SciChartReact } from "scichart-react";
import { ESeriesType, EThemeProviderType } from "scichart";

/**
 * The chart configuration object acceptable by the Builder API
 * @type {import("scichart").TSurfaceDefinition}
 */
const chartConfig = {
  surface: {
    theme: { type: EThemeProviderType.Dark },
    title: "Basic Chart via Config",
    titleStyle: {
      fontSize: 20,
    },
  },
  series: {
    type: ESeriesType.SplineMountainSeries,
    options: {
      strokeThickness: 4,
      stroke: "#216939",
      fillLinearGradient: {
        startPoint: { x: 0, y: 0 },
        endPoint: { x: 1, y: 1 },
        gradientStops: [
          { offset: 0.3, color: "#2d2169" },
          { offset: 1, color: "transparent" },
        ],
      },
    },
    xyData: { xValues: [0, 1, 2, 3, 4], yValues: [3, 6, 1, 5, 2] },
  },
};

export const BasicChart = () => (
  <SciChartReact style={{ width: 400, height: 300 }} config={chartConfig} />
);

Here’s the output

Note SciChartReact extends properties of the HTMLDivElement and propagates them to the underlying div element.

Create a React Chart with Programmatic API

Alternatively, SciChartReact accepts an initialization function. This allows the creation of a chart with the usual SciChart.js API. In this case the chartInitializationFunction below must be async and accepts the

rootElement created by scichart-react as a parameter. This can be passed straight to SciChartSurface.create().

import { SciChartReact } from "scichart-react";
import {
  EThemeProviderType,
  NumericAxis,
  SciChartSurface,
  SplineMountainRenderableSeries,
  XyDataSeries,
} from "scichart";
/**
 * A function executed within SciChartReact with provided chart root element,
 * creates a SciChartSurface instance and returns a reference to it.
 *
 * @param {string | HTMLDivElement} rootElement
 * @returns {Promise<{sciChartSurface: SciChartSurface}>}
 */
const chartInitializationFunction = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: { type: EThemeProviderType.Dark },
      title: "Basic Chart via Init Function",
      titleStyle: {
        fontSize: 20,
      },
    }
  );

  sciChartSurface.xAxes.add(new NumericAxis(wasmContext));
  sciChartSurface.yAxes.add(new NumericAxis(wasmContext));
  sciChartSurface.renderableSeries.add(
    new SplineMountainRenderableSeries(wasmContext, {
      dataSeries: new XyDataSeries(wasmContext, {
        xValues: [0, 1, 2, 3, 4],
        yValues: [3, 6, 1, 5, 2],
      }),
      strokeThickness: 4,
      stroke: "#216939",
      fillLinearGradient: {
        startPoint: { x: 0, y: 0 },
        endPoint: { x: 1, y: 1 },
        gradientStops: [
          { offset: 0.3, color: "#2d2169" },
          { offset: 1, color: "transparent" },
        ],
      },
    })
  );

  return { sciChartSurface };
};

export const BasicChartWithInitFunction = () => (
  <SciChartReact
    style={{ width: 400, height: 300 }}
    initChart={chartInitializationFunction}
  />
);

Additionally, it is possible to easily add more customizations and functionality by providing arguments to other props:

fallback – a JSX element to render while the chart initialization is in progress
onInit – a callback that is executed after the chart initialization has been completed
onDelete – a callback executed when a fully initialized chart is unmounted

Advanced React Chart example – Selection and Synchronization with a DataGrid

Let’s look at another more complex example:

For this case, we will take a setup with a Scatter Chart that fetches data asynchronously.
The points on the chart could be selected by click and drag action.
Upon selection, the point info appears within a grid at the side of the chart

Step 1 – Fetching Data Asynchronously and loading the Chart

Considering that the data fetching as well as a chart initialization potentially can take a noticeable amount of time, let’s make sure to set a custom loading UI with fallback property.

/**
 * @param {string | HTMLDivElement} rootElement
 * @returns {Promise<{sciChartSurface: SciChartSurface}>}
 */
const chartInitializationFunction = async (rootElement) => {
  const createChart = async () => {
    // for demonstration purposes, here we have used Builder API explicitly
    const { sciChartSurface } = await chartBuilder.build2DChart(rootElement, {
      xAxes: {
        type: EAxisType.NumericAxis,
        options: {
          autoRange: EAutoRange.Once,
          growBy: new NumberRange(0.2, 0.2),
        },
      },
      yAxes: {
        type: EAxisType.NumericAxis,
        options: { autoRange: EAutoRange.Never },
      },
      surface: {
        theme: { type: EThemeProviderType.Dark },
        title: "Scatter Chart",
        titleStyle: {
          fontSize: 20,
        },
      },
    });

    return sciChartSurface;
  };

  // a function that simulates an async data fetching
  const getData = async () => {
    await new Promise((resolve) => {
      setTimeout(() => resolve({}), 1500);
    });

    return { xValues: [0, 1, 2, 3, 4], yValues: [3, 6, 1, 5, 2] };
  };

  const [sciChartSurface, data] = await Promise.all([createChart(), getData()]);

  const wasmContext = sciChartSurface.webAssemblyContext2D;

  sciChartSurface.renderableSeries.add(
    new XyScatterRenderableSeries(wasmContext, {
      dataSeries: new XyDataSeries(wasmContext, {
        ...data,
      }),
      strokeThickness: 4,
      stroke: "#216939",
    })
  );
  return { sciChartSurface };
};

// ...
// then in JSX
// ...

<SciChartReact
  style={{ width: "50%", height: 300 }}
  fallback={
    <div className="fallback">
      <div>Data fetching & Chart Initialization in progress</div>
    </div>
  }
  initChart={chartInitializationFunction}
/>

Step 2 – Adding in Selection Behavior to the Chart

To achieve this behavior we can use DataPointSelectionModifier, which is a built-in behaviour in SciChart to allow selection, and multi-selection of data-points on a chart.

  // ...

  /**  
   * @param {{sciChartSurface: SciChartSurface}} initResult 
   *    - a resolved object returned by the initialization function 
   */
  const onChartInitializationComplete = (initResult) => {
    const dataPointSelectionModifier = new DataPointSelectionModifier({
      allowClickSelect: true,
      allowDragSelect: true,
      selectionStroke: "lime",
      selectionFill: "#ff879f33",
      onSelectionChanged: (args) =>
        setSelectedPoints([...(args?.selectedDataPoints || [])]),
    });

    initResult.sciChartSurface.chartModifiers.add(dataPointSelectionModifier);
  };

  const onChartCleanup = () => setSelectedPoints([]);

  // ...

  <SciChartReact
    style={{ width: "50%", height: 300 }}
    fallback={
      <div className="fallback">
        <div>Data fetching & Chart Initialization in progress</div>
      </div>
    }
    initChart={chartInitializationFunction}
    onInit={onChartInitializationComplete}
    onDelete={onChartCleanup}
  />

Step 3 – Synchronising Selection Data from a Chart to a DataGrid

Now to bind the point selection to a grid, we are adding an appropriate callback to the DataPointSelectionModifier – onSelectionChanged.
It can be used to get the list of the selected points and then we should be able to easily put them into a grid.

// ...

<div className="flex-container">
  <SciChartReact
    style={{ width: "50%", height: 300 }}
    fallback={
      <div className="fallback">
      <div>Data fetching & Chart Initialization in progress</div>
      </div>
    }
    initChart={chartInitializationFunction}
    onInit={onChartInitializationComplete}
    onDelete={onChartCleanup}
  />

  <div className="data-grid">
    <div className="grid-cell grid-header">
      <div>Selected Points</div>
    </div>
    <div className="grid-cell column-header">
      <div>X Value</div>
    </div>
    <div className="grid-cell column-header">
      <div>Y Value</div>
    </div>

    {selectedPoints.map((point) => (
      <>
        <div key={`x-val-${point.index}`} className="grid-cell">
          <div>{point.xValue}</div>
        </div>
        <div key={`y-val-${point.index}`} className="grid-cell">
           <div>{point.yValue}</div>
        </div>
      </>
    ))}
  </div>
</div>

Further Examples of React Charts with scichart-react

The full source-code for all three examples in this blog post, showing how to create a Basic React Chart with config, a Basic Chart with programmatic API, as well as the DataGrid sync example are included in the Codesandbox here.
Additional resources can be found below.

Simple Examples: SciChart-react code examples – Github Pages
Source: SciChart-React source-code on Github
npm: SciChart-React package on npm
Advanced examples: we’re working through the SciChart.js Demo to update all our examples to use scichart-react. ## Conclusion
Integrating SciChart with React for Powerful Charting
It has always been possible to use SciChart’s JavaScript Charts within React. We previously documented how to create a reusable react component talking about some of the issues such as correct component lifecycle and handling SciChart’s async initialisation.

We’ve now wrapped this up into an open source library called scichart-react to make creating React Charts easy.