9 releases

0.3.6 May 20, 2024
0.3.5 Jun 16, 2023
0.3.4 Jul 6, 2022
0.3.2 Jul 2, 2021
0.0.1 Feb 4, 2020

#39 in Visualization

Download history 406464/week @ 2024-03-14 417924/week @ 2024-03-21 419831/week @ 2024-03-28 442887/week @ 2024-04-04 462960/week @ 2024-04-11 460231/week @ 2024-04-18 447136/week @ 2024-04-25 466507/week @ 2024-05-02 452417/week @ 2024-05-09 479932/week @ 2024-05-16 491006/week @ 2024-05-23 576290/week @ 2024-05-30 582974/week @ 2024-06-06 586593/week @ 2024-06-13 595535/week @ 2024-06-20 518053/week @ 2024-06-27

2,398,895 downloads per month
Used in 4,984 crates (23 directly)

MIT license


plotters-backend - The base crate for implementing a backend for Plotters

This is a part of plotters project. For more details, please check the following links:


The Plotters backend API crate. This is a part of Plotters, the Rust drawing and plotting library, for more details regarding the entire Plotters project, please check the main crate.

This is the crate that used as the connector between Plotters and different backend crates. Since Plotters 0.3, all the backends has been hosted as separate crates for the usability and maintainability reasons.

At the same time, Plotters is now supporting third-party backends and all the backends are now supports "plug-and-play": To use a external backend, just depends on both the Plotters main crate and the third-party backend crate.

Notes for implementing Backend for Plotters

To create a new Plotters backend, this crate should be imported to the crate and the trait DrawingBackend should be implemented. It's highly recommended that the third-party backend uses plotters-backend by version specification ^x.y.*. For more details, see the compatibility note.

If the backend only implements DrawingBackend::draw_pixel, the default CPU rasterizer will be used to give your backend ability of drawing different shapes. For those backend that supports advanced drawing instructions, such as, GPU accelerated shape drawing, all the provided trait method can be overridden from the specific backend code.

If your backend have text rendering ability, you may want to override the DrawingBackend::estimate_text_size to avoid wrong spacing, since the Plotters default text handling code may behaves differently from the backend in terms of text rendering.

Animated or Realtime Rendering

Backend might render the image realtimely/animated, for example, a GTK backend for realtime display or a GIF image rendering. To support these features, you need to play with ensure_prepared and present method. The following figure illustrates how Plotters operates a drawing backend.

  • ensure_prepared - Called before each time when plotters want to draw. This function should initialize the backend for current frame, if the backend is already prepared for a frame, this function should simply do nothing.
  • present - Called when plotters want to finish current frame drawing
.ensure_prepared() &&
+-------------+    +-------------+    .draw_pixels()             +--------------+   drop
|Start drawing|--->|Ready to draw| ------------------------+---->|Finish 1 frame| --------->
+-------------+    +-------------+                         |     +--------------+
^                  ^                                |            |
|                  +------------------------------- +            |
|                            continue drawing                    |
start render the next frame
  • For both animated and static drawing, DrawingBackend::present indicates current frame should be flushed.
  • For both animated and static drawing, DrawingBackend::ensure_prepared is called every time when plotters need to draw.
  • For static drawing, the DrawingBackend::present is only called once manually, or from the Drop impl for the backend.
  • For dynamic drawing, frames are defined by invocation of DrawingBackend::present, everything prior the invocation should belongs to previous frame

Compatibility Note

Since Plotters v0.3, plotters use the "plug-and-play" schema to import backends, this requires both Plotters and the backend crates depends on a same version of plotters-backend crate. This crate (plotters-backend) will enforce that any revision (means the last number in a version number) won't contains breaking change - both on the Plotters side and backend side.

Plotters main crate is always importing the backend crate with version specification plotters-backend = "^<major>.<minor>*". It's highly recommended that all the external crates follows the same rule to import plotters-backend dependency, to avoid potential breaking caused by plotters-backend crates gets a revision update.

We also impose a versioning rule with plotters and some backends: The compatible main crate (plotters) and this crate (plotters-backend) are always use the same major and minor version number. All the plotters main crate and second-party backends with version "x.y.*" should be compatible, and they should depens on the latest version of plotters-backend x.y.*

No runtime deps