Configurable framebuffer size at compilation time

[Szybet]

But it doesn't work?
Small hacky code I have:

    let spi = BareSpiDevice {mosi, sck};

    let mut display = wepd::Display::new(DisplayConfiguration {
        spi: spi,
        dc: dc,
        rst: rst,
        busy: busy,
        delay: Delay,
        busy_wait: DelayWaiter::new(Delay)
        .with_timeout_ms(100_000)
        .with_delay_ms(1),
    })
    .unwrap();

    send_debug_message(LPOG_SCREEN_INIT_4);

    display.reset().unwrap();

    send_debug_message(LPOG_SCREEN_FIRST_ACTION_5);

    // To clear the screen to white, otherwise it doesn't clear itself!
    display.clear_screen(0xFF).unwrap();

    Delay.delay_millis(1000);

    let mut fb: wepd::Framebuffer<45, 80> = wepd::Framebuffer::new();
    
    let thin_stroke = PrimitiveStyle::with_stroke(wepd::Color::Black, 5);

    let yoffset = 10;
    // Draw a triangle.
    Line::new(Point::new(0, 0), Point::new(45, 80))
    .into_styled(thin_stroke)
    .draw(&mut fb).unwrap();
    
    fb.flush(&mut display, 100, 100).unwrap();

    Delay.delay_millis(1000);
    
    send_debug_message(LPOG_SCREEN_END_6);

    display.power_off().unwrap();

[Szybet]

Oh, it also requires nightly, in rust-toolchain.toml

[toolchain]
channel = "nightly-2024-07-22"

[Szybet]

It fails at this rect.intersection if, but not error is returned

Oh, nevermind, let me test further then

lo refers to the lower (or starting) bound of the range for a coordinate (e.g., the left or top side of the rectangle).
hi refers to the upper (or ending) bound of the range for a coordinate (e.g., the right or bottom side of the rectangle).

it still draws crap, here is a more refined example:

    let mut fb: wepd::Framebuffer<56, 56> = wepd::Framebuffer::new();
        
    let thin_stroke = PrimitiveStyle::with_stroke(wepd::Color::Black, 3);

    Line::new(Point::new(0, 0), Point::new(24, 24))
    .into_styled(thin_stroke)
    .draw(&mut fb).unwrap();

    Circle::new(Point::new(25, 25), 5)
        .into_styled(thin_stroke)
        .draw(&mut fb).unwrap();

    fb.flush(&mut display, 100, 100).unwrap();

the framebuffer needs to be divisable by 8, do we just make some asserts about it?

And well, it still doesn't work, at least it outputs garbage to the screen now

[Szybet]

framebuffer flush could look like that now:

    pub fn flush<C: IsDisplayConfiguration>(
        &mut self,
        display: &mut Display<C>,
        x_lo: i16,
        y_lo: i16,
    ) -> Result<(), Error<C>> {
        display.draw_image(
            &self.framebuffer,
            x_lo,
            y_lo,
            x_lo + FB_WIDTH as i16,
            y_lo + FB_HEIGHT as i16,
        )
    }

but it still doesn't work...

[invpt]

so it looks like you are changing so that framebuffer is smaller to make it possible to update smaller screen areas

What if instead the FB detected the area that was modified and itself computes the partial update area that must be used?

[invpt]

That was the idea I had originally but I dunno if it fulfills your usecase

[Szybet]

so it looks like you are changing so that framebuffer is smaller to make it possible to update smaller screen areas

What if instead the FB detected the area that was modified and itself computes the partial update area that must be used?

I don't have 5kb of memory for 200 * 200 / 8, in fact its 70% of the total memory I have :D

I tested further, it works when i do the size 200 200 and at 0 0 but otherwise it gets messy, somewhere the math is done wrong

[invpt]

Oh boy alright lol, I'll take a look at this when I am able to and figure out what's up

[Szybet]

Thanks, I looked into it but I haven't found anything

[Szybet]

Oh
It works when both size and the location is dividable by 8
So you somewhere skipped the math to handle that

[Szybet]

very unsure about the hibernation things, but it works