epd-waveshare icon indicating copy to clipboard operation
epd-waveshare copied to clipboard

EPD super slow in comparison to python library

Open caemor opened this issue 4 years ago • 4 comments

See #33 for more info. But in short:

This seems to be about twice as slow to write to the screen as the Waveshare Python controller (specifically the July 10 2017 version, which is what I currently have hooked up to my screen), despite using the same panel settings.

Measuring some drawing times (DATA_START_TRANSMISSION_1 + DISPLAY_REFRESH):

* Old Python driver: 24s
  
  * Buffer is 30720 bytes (`= HEIGHT * WIDTH / 8`)
  * Writes 4 data bytes per buffer byte

* Latest Python driver: 30s
  
  * Buffer is `HEIGHT * WIDTH / 4` bytes
  * Writes 2 data bytes per buffer byte

* This Rust driver: 53s
  
  * Buffer is `HEIGHT * WIDTH / 8` bytes
  * Writes 4 data bytes per buffer byte

Tested on a raspberry pi zero w by @str4d

caemor avatar Nov 20 '19 15:11 caemor

@str4d: You were using the oldest link from here? https://www.waveshare.com/wiki/File:7.5inch-e-paper-hat-code.7z or did you try their github: https://github.com/waveshare/e-Paper/tree/master/RaspberryPi%26JetsonNano/python/examples ?

caemor avatar Nov 20 '19 15:11 caemor

The "Old Python driver" test does indeed use the driver from the oldest link on that wiki page. The "Latest Python driver" test used whatever was in latest master of their repo at the time of testing.

str4d avatar Nov 21 '19 01:11 str4d

I suspect that if people want to try to implement the faster updates this would be the place to look: https://github.com/repaper/gratis/. The python "driver" just writes to a FUSE filesystem backed by C.

frioux avatar Dec 25 '21 02:12 frioux

Hi there,

I may have misunderstood, but the initial reporter said that it was way longer to write on the e-paper using this crate, versus the python equivalent.

In my case, I've the epd7in5 (first version) and it was also faaaar longer to put a simple text on the screen than the equivalent python version

It tooks ~ 30 seconds in the update_frame() function

Here is my quick test :

hardware :

  • raspberry pi zero w
  • 7.5inch HD e-Paper HAT (https://www.waveshare.com/wiki/7.5inch_HD_e-Paper_HAT)
    let mut delay = Delay;

    let mut epd7in5 = Epd7in5::new(&mut spi, busy, dc, rst, &mut delay, None).expect("eink initalize error");

    let mut display = Display7in5::default();

    println!("here_1 {}", Local::now());
    display.set_rotation(DisplayRotation::Rotate0);
    draw_text(&mut display, &my_string_utc, 20, 20);

    println!("here_2 {}", Local::now());
    epd7in5.update_frame(&mut spi, display.buffer(), &mut delay)?;
    println!("here_3 {}", Local::now());
    epd7in5
        .display_frame(&mut spi, &mut delay)
        .expect("display frame new graphics");

    println!("here_4 {}", Local::now());
    let new_delay: u32 = 7000;
    println!("Set delay to {} ms", new_delay);
    delay.delay_ms(new_delay);

    println!("Finished tests - going to sleep");
    epd7in5.sleep(&mut spi, &mut delay)
here_1 2024-02-28 21:03:32.851235119 +01:00
here_2 2024-02-28 21:03:32.852281108 +01:00
here_3 2024-02-28 21:04:08.387091203 +01:00            <= MORE THAN 30 seconds btw these 2 steps !
here_4 2024-02-28 21:04:08.388867185 +01:00
Set delay to 7000 ms
Finished tests - going to sleep

Any idea on how to improve this ?

Thanks

kburgi avatar Feb 28 '24 20:02 kburgi