QtChart vs PyQtGraph

Comparing performance, popularity, and licensing for Python GUI plotting
Heads up! You've already completed this tutorial.

I'm building a Python GUI application that needs plotting/charting. Should I use QtChart or PyQtGraph? How do they compare in terms of performance, community support, and licensing?

If you're building a Python GUI application that needs plotting or charting capabilities, you've likely come across two prominent options: QtChart (part of the Qt framework) and PyQtGraph (a community-built plotting library). Both integrate naturally with PyQt5 and PySide2 applications, but they take quite different approaches to the problem of drawing charts in a Qt window.

This article walks through the practical differences between the two libraries, covering performance characteristics, popularity and community support, and licensing — so you can make an informed choice for your next project.

What Are These Libraries?

PyQtGraph is a pure-Python plotting library built on top of Qt's QGraphicsScene framework and NumPy. It was designed from the ground up for speed and interactivity in scientific and engineering applications. Because it's built on NumPy, it benefits from NumPy's highly optimized C and Fortran internals for data handling and array operations.

QtChart (accessed in Python via PyQtChart or the PySide2/PySide6 QtCharts module) is the official charting module provided by the Qt Company. It's written in C++ as part of the Qt libraries, with Python bindings generated in the same way as the rest of PyQt5 or PySide2. QtChart provides a more traditional charting API with bar charts, pie charts, line charts, and other standard chart types.

Popularity and Community Support

PyQtGraph has a significant head start in terms of community adoption. It has been available and actively used for many years, with a mature ecosystem of examples, documentation, and community knowledge.

QtChart's Python bindings arrived comparatively late. Looking at the PyQtChart package on PyPI, releases only go back to PyQt5.7 in 2016. Four years is a reasonable amount of time, but when an established alternative like PyQtGraph already exists and works well, many developers simply stuck with what they knew.

This late start has had a compounding effect: because fewer people were using QtChart from Python, fewer tutorials and examples were written, which in turn made it harder for new developers to pick it up. PyQtGraph, by contrast, has a wealth of community-contributed examples already out there, making common tasks easy to accomplish.

That said, QtChart's documentation on the C++ side is excellent (it's maintained by the Qt Company), and translating C++ Qt examples to Python is usually straightforward once you're comfortable with the pattern.

Performance

This is the question most people want answered, and the answer depends on your specific use case.

In principle, QtChart could be faster for certain operations. It's pure C++ with no Python overhead, no Global Interpreter Lock (GIL) involvement, and no transitions between Python and C during rendering. All the chart drawing happens inside compiled Qt code.

PyQtGraph, on the other hand, involves more Python code in the plotting pipeline. Your data goes through Python and NumPy, gets converted through the PyQt/PySide bindings, and is then placed onto a QGraphicsScene — which is itself a Qt C++ object. So the initial plot construction involves more Python, but once the scene is built, operations like panning and zooming are handled by Qt's C++ graphics engine.

In Practice

The real-world differences are often much smaller than you might think.

For static or slowly-updating plots, the bottleneck is rarely the plotting library itself. If you're plotting 40,000 points collected over a day (say, one sample every 2 seconds), both libraries will handle this without difficulty. The rendering of that many points is fast in either case.

For interactive operations like zooming and panning, PyQtGraph's use of QGraphicsScene means that once the plot is drawn, the interactivity is largely handled in C++ by Qt. You're not re-running Python code every time you drag the view around — Qt's scene graph takes care of it.

Where things get slow often has more to do with what you're drawing than which library you're using. Drawing thick lines (with a wide pen width) is significantly more expensive than drawing thin lines or simple point markers, regardless of the library. A line with a pen width greater than 1 pixel requires Qt to calculate the geometric outline of the stroke, which is much more work than a simple 1-pixel line. Similarly, markers with outlines and fills cost more than plain dots.

If you're experiencing sluggish zooming and panning with tens of thousands of points, try these things before switching libraries:

  • Reduce pen width to 1 pixel, or use cosmetic pens (which don't scale with zoom).
  • Simplify markers — remove outlines or fills you don't strictly need.
  • Downsample visible data — when zoomed out, you don't need to draw every single point. PyQtGraph has built-in downsampling support via the downsample and autoDownsample options on PlotDataItem.
  • Disable antialiasing if visual smoothness isn't critical for your application.

Benchmarking Tips

If you want to compare the two libraries for your specific use case, a good approach is to create a test with a large number of data points — a few million, for example — and draw them as a line series. Then interact with the plot: pan around, zoom in and out, and see which library feels more responsive.

Be aware that the built-in zoom and pan interactions work differently between the two libraries, so a fair comparison requires some work to normalize the interaction model. You might measure frame render times programmatically rather than relying purely on subjective feel.

Here's a minimal PyQtGraph test you could use as a starting point:

python
import numpy as np
import pyqtgraph as pg
from pyqtgraph.Qt import QtWidgets

app = QtWidgets.QApplication([])

# Generate test data.
n_points = 1_000_000
x = np.linspace(0, 100, n_points)
y = np.sin(x) + np.random.normal(scale=0.1, size=n_points)

win = pg.PlotWidget(title="PyQtGraph Performance Test")
win.plot(x, y, pen=pg.mkPen(width=1))
win.show()

app.exec()

And a comparable QtChart version:

python
import numpy as np
from PyQt5.QtWidgets import QApplication, QMainWindow
from PyQt5.QtChart import QChart, QChartView, QLineSeries
from PyQt5.QtCore import QPointF

app = QApplication([])

n_points = 1_000_000
x = np.linspace(0, 100, n_points)
y = np.sin(x) + np.random.normal(scale=0.1, size=n_points)

series = QLineSeries()
points = [QPointF(float(x[i]), float(y[i])) for i in range(n_points)]
series.replace(points)

chart = QChart()
chart.addSeries(series)
chart.createDefaultAxes()
chart.setTitle("QtChart Performance Test")

view = QChartView(chart)
window = QMainWindow()
window.setCentralWidget(view)
window.resize(800, 600)
window.show()

app.exec()

Try varying n_points and the pen width, and see where each library starts to struggle. You'll likely find that the differences are situational rather than one library being universally faster.

Licensing

Licensing is an area where the two libraries differ significantly, and it's worth understanding before you commit to either one.

PyQtGraph is licensed under the MIT license. This is a very permissive open-source license — you can use PyQtGraph in commercial, closed-source applications without any licensing fees or obligations beyond including the copyright notice.

QtChart has a more nuanced licensing situation. Under the Qt framework, QtChart is available under the GPLv3 license for open-source projects, or under a commercial Qt license for proprietary applications. This means:

  • If your application is open source and GPL-compatible, you can use QtChart freely.
  • If your application is proprietary or commercial, you'll need a commercial Qt license to use QtChart — which involves a per-developer cost.

The core Qt Widgets and Qt GUI modules are available under the LGPLv3, which allows use in commercial applications without a commercial license (as long as you dynamically link to Qt). But QtChart specifically is not available under LGPL — it's GPL or commercial only.

This licensing difference is one practical reason why many developers choose PyQtGraph, especially for commercial or closed-source projects.

If you're using PySide2 or PySide6 (the Qt for Python bindings from the Qt Company), the QtCharts module follows the same licensing terms as the rest of the Qt framework — LGPLv3 for the core modules, but GPL for add-on modules like QtCharts. Check the Qt licensing page for the latest details, as terms can change between releases.

Feature Comparison

Beyond performance and licensing, the two libraries have different strengths in terms of features:

Feature PyQtGraph QtChart
Line plots
Scatter plots
Bar charts ✓ (basic) ✓ (full-featured)
Pie charts
Real-time updating ✓ (excellent) ✓ (good)
Image display
3D plotting ✓ (via GLViewWidget) ✗ (separate Qt Data Visualization module)
Built-in downsampling
ROI tools
NumPy integration ✓ (native) ✗ (manual conversion)
Crosshair/cursor tools Manual implementation
License MIT GPL / Commercial

PyQtGraph shines for scientific and engineering applications where you need fast, interactive data exploration with features like regions of interest (ROIs), image views, and tight NumPy integration. QtChart is better suited for business-style charts and dashboards where you need polished bar charts, pie charts, and other standard chart types with a clean, professional look out of the box.

Which Should You Choose?

Here are some guidelines based on common scenarios:

Choose PyQtGraph if:

  • You're working with scientific or engineering data
  • You need real-time or frequently updating plots
  • You want tight NumPy integration without manual data conversion
  • Your application is commercial or closed-source (MIT license)
  • You need interactive tools like ROIs, crosshairs, or image display
  • You're plotting large datasets and want built-in downsampling

Choose QtChart if:

  • You need standard business chart types (pie charts, stacked bars, etc.)
  • Visual polish and professional chart styling are priorities
  • Your application is open source (GPL-compatible) or you have a commercial Qt license
  • You prefer working within the official Qt ecosystem for all components
  • Your datasets are moderate in size and you don't need specialized scientific tools

Consider both if you're just exploring — try each with your actual data and your actual use case. A quick prototype with each library will tell you more than any benchmark article can.

Summary

Both QtChart and PyQtGraph are capable plotting solutions for Python Qt applications. PyQtGraph has broader community adoption, more permissive licensing, and better support for scientific workflows. QtChart offers polished standard chart types and the backing of the Qt Company, but comes with GPL licensing restrictions for commercial use.

On performance, the differences are often smaller than expected. The real bottlenecks tend to be in what you're drawing (pen widths, marker complexity, antialiasing) rather than which library is doing the drawing. If you're hitting performance limits, optimizing your drawing approach — reducing pen width, enabling downsampling, simplifying markers — will likely give you bigger gains than switching libraries.

Well done, you've finished this tutorial! Mark As Complete
[[ user.completed.length ]] completed [[ user.streak+1 ]] day streak

Create GUI Applications with Python & Qt6 by Martin Fitzpatrick

(PyQt6 Edition) The hands-on guide to making apps with Python — Over 15,000 copies sold!

More info Get the book

Martin Fitzpatrick

QtChart vs PyQtGraph was written by Martin Fitzpatrick.

Martin Fitzpatrick has been developing Python/Qt apps for 8 years. Building desktop applications to make data-analysis tools more user-friendly, Python was the obvious choice. Starting with Tk, later moving to wxWidgets and finally adopting PyQt. Martin founded PythonGUIs to provide easy to follow GUI programming tutorials to the Python community. He has written a number of popular Python books on the subject.