GxEPD2_4G 750_GDEY075T7 fast partial refresh with paged GFX not working

[witherhunter06]

Hello there!

I have the 750_GDEY075T7 display, I bought it because of the gray levels and fast refresh capabilities, and have tried some of the rendering examples.

There was this example that has fascinated me the most: drawBitmaps4g_I6FD_128x296

On this display it refreshes the images (non-4g) so fast AND without flashing the whole screen or even the area it updates!
And I was thinking: "neat! i can render my text instantly partially", after i set up a simple demo to tinker with some elements, i got utterly disappointed... it did a full refresh every time, even when setting setPartialWindow(...)

demo code i used to test:

void drawMenu() {
    uint16_t width = 160;
    uint16_t padding = 8;

    uint16_t box_x = display.width() - width;
    uint16_t box_y = padding;
    uint16_t box_w = width - padding;
    uint16_t box_h = display.height() - padding * 2;

    const char MENU[] = "MENU";

    int16_t tbx, tby;
    uint16_t tbw, tbh;
    display.getTextBounds(MENU, 0, 0, &tbx, &tby, &tbw, &tbh);

    display.setRotation(0);
    display.setPartialWindow(box_x, box_y, box_w, box_h);
    display.firstPage();
    do {
        display.drawRoundRect(box_x, box_y, box_w, box_h, 4, GxEPD_BLACK);
        display.setCursor(box_x, box_y + tbh);
        display.setTextColor(GxEPD_BLACK);
        display.print(MENU);

        display.setFont(&FreeMono12pt7b);

        for (uint8_t i = 1; i < 5; i++) {
            String ITEM = "Item: " + String(i);

            int16_t tbx1, tby1;
            uint16_t tbw1, tbh1;
            display.getTextBounds(ITEM, 0, 0, &tbx1, &tby1, &tbw1, &tbh1);

            display.setCursor(box_x + 4, box_y + (tbh * 2) + ((tbh1 + 4) * i));
            display.setTextColor(GxEPD_BLACK);
            display.print(ITEM);
        }
    } while (display.nextPage());
}

then i went to the GxEPD2_750_GDEY075T7.h file to look at the config and saw that the use of partial window (usePartialUpdateWindow) was set to false... i tried to overwrite it with true, and yes it looked horrible, i am glad it is set to false per default..

BUT NOW HERE IS THE THING: why can display.writeImage(...) render a bitmap perfectly, instantly, without flashes and without affecting the rest of the already rendered content, but the display.nextPage() method reloads everything regardless...

my wish is to simply set the cursor to my text value i want to update, say display.print(...) and see it update instantly without flashing the screen... just as if i were doing it with display.writeImage(...) and a bitmap

is it because the display.nextPage() function calls epd2.writeImage_4G(...) instead of epd2.writeImage(...) for everything, even black and white only?

or is there just something that i am overlooking completely...
any help appreciated

[silentobserver]

Hi @witherhunter06

See README.md

• on GDEY075T7 grey level partial window update looks bad (greys out remainder)
• on GDEY075T7 grey level partial window update is disabled by default

and GxEPD2_4G_MixedExample_display_selection.h

// these panels don't support mixed content because clearing the background before changing refresh mode
//#define GxEPD2_DRIVER_CLASS GxEPD2_750_GDEY075T7 // GDEY075T7 800x480, UC8179 (GD7965), (FPC-C001 20.08.20)

[witherhunter06]

hey @silentobserver thanks for the reply!

i have seen the warnings/notices you have posted, on the repo before, but i thought that they only apply when you want to render colors other than black and white, or does black and white also count as grey level in this case..?

yesterday i have decided to try and look for a manufacturers demo, and found this esp32 demo code from good display here: https://www.good-display.com/companyfile/1125.html
i have tried their partial, fast refresh and fast partial refresh examples and it is totally a different experience from gxepd2-4g, it works exactly how i thought it would be, now i just need some adafruit gfx implementation and it would be golden !

they do make a difference on how to start rendering.. e.g. if you want to display a 4-grey level bitmap, then you have to call a specific 4g initializer, if you want to render fast then you also have to call that specific fast init beforehand...
as i understood it, gxepd2-4gs nextPage() calls writeImage4g() regardless of colors used... wouldn't the fix be super simple? check if any of the bit colors is not pure black and white and only then take writeImage4g(), otherwise use the normal writeImage()

let me know if i am on the wrong track with this thought, but this is the thing that comes up as a "simple" fix. Maybe i could even try to modify the lib in the evening to try this out...