ST7789 offset issue with `embedded-text`

[brxken128]

For some reason, using mipidsi with textboxes from embedded-text seems to produce a weird cut-off issue if the display has a pretty harsh offset. To preface, I'm unsure whether this issue is with mipidsi or with embedded-text, but it's probably best that the issue is tracked somewhere.

About the setup: I'm using an Adafruit Feather ESP32-S3 (TFT), with esp-hal. The TFT attached to the board is a 240x135 ST7789, with the SKU ADA4383. From my testing with a filled box and a contrasting stroke colour, it seems to have similar offsets to the pico1 model, which is why that's used in my code below (along with mipidsi 0.5.0).

Text just appears to get cut-off at a seemingly arbitrary point on the display, no matter what. I have tried extending the text box, changing rotations, using different display models (in the code, not hardware), starting points, height modes, etc. None of them seem to allow text to be printed over this arbitrary cut-off point.

let di = SPIInterfaceNoCS::new(interface, dc);

let mut display = Builder::st7789_pico1(di)
    .with_display_size(240, 135)
    .with_orientation(Orientation::Landscape(true))
    .init(Delay::get_delay_mut(), Some(rst))
    .unwrap();

display.clear(Rgb565::BLACK).unwrap();

let text_style = MonoTextStyleBuilder::new()
    .font(&FONT_9X15)
    .text_color(Rgb565::WHITE)
    .build();

let textbox_style = TextBoxStyleBuilder::new()
    .alignment(HorizontalAlignment::Center)
    .vertical_alignment(VerticalAlignment::Middle)
    .build();

let bounds = Rectangle::new(Point::zero(), Size::new(235, 130));

let text_box = TextBox::with_textbox_style(text, bounds, text_style, textbox_style);

text_box.draw(display).unwrap();

The text below is supposed to say "1Player", but it doesn't show further than the P. It's not dead-centre as this was an attempt while I tried to use a wider textbox, but this issue persists no matter what.

Solid colours still fill as expected, and below is a picture of a red fill (apologies for the bad photo, it is red). This box is using the exact same bounds as the textbox, just with a solid red fill.

[rfuest]

I've just tried your code on very similar hardware, a LILYGO T-Display S3 with a ESP32-S3 and a ST7789 based display. The only difference is that my display has a resolution of 170x320 pixels. Everything works as expected: For the image I replaced the bounds with display.bounding_box(), but it also worked with the values in your code.

Did you try other drawing operations to see if they work correctly? You could, for example, try to draw the same text without using embedded-text. This code should draw "ABC" into each corner of the display:

let bb = display.bounding_box().offset(-20);
for anchor in [
    AnchorPoint::TopLeft,
    AnchorPoint::TopCenter,
    AnchorPoint::TopRight,
    AnchorPoint::CenterLeft,
    AnchorPoint::Center,
    AnchorPoint::CenterRight,
    AnchorPoint::BottomLeft,
    AnchorPoint::BottomCenter,
    AnchorPoint::BottomRight,
]
.into_iter()
{
    Text::with_text_style("ABC", bb.anchor_point(anchor), character_style, text_style)
        .draw(&mut display)
        .unwrap();
}

[almindor]

This seems unlikely to be caused by the driver but there could be some oddity going on. Can you draw something non-rectangular like circles in the area where you'd get cut off with the font?

There is no difference to how things are rendered by the driver when it comes to non-rectangular shapes. They get translated to essentially small rectangles and filled in with some buffering in place, but it's the same for pretty much any shape. Rects are faster because they need less window addressing calls though, so drawing something more complex might reveal the issue without using fonts.

[9names]

Can confirm that it's doing weird stuff with a Pico display: @rfuest: This is your test program put on top of my original test program from https://github.com/almindor/mipidsi/issues/27

gist for anyone interested: https://gist.github.com/9names/126f4f15f05e9e80b858405876e3cf5c

[9names]

spotted the problem. should be: .with_display_size(135, 240)

[9names]

This is with the above change

I wonder what's causing the glitches in the background image...

[9names]

well it's not the text, and the corruption moves around every reset

[brxken128]

spotted the problem. should be: .with_display_size(135, 240)

Well, this is embarrassing.

I apologise for all of the fuss, it appears I tried everything except arguably the most basic solution.

Thank you so much, I had just assumed the display was permanently in landscape mode unless instructed otherwise.

(I can confirm this fixes the issue, and I don't know why I didn't even attempt this one sooner. Thank you!)

[9names]

is the output glitch-free for you? I'm trying to work out if it's something i'm doing, something rp2040 specific, or something else.

[brxken128]

is the output glitch-free for you? I'm trying to work out if it's something i'm doing, something rp2040 specific, or something else.

I can give it a shot in a sec and send you the results.

[brxken128]

This is the output I get using the same display code as in the gist you sent. I can't visually see any artifacts, or anything that looks out of place.

[9names]

Thanks! That looks perfect, I'll have to debug my own issues then :D

[brxken128]

Thanks! That looks perfect, I'll have to debug my own issues then :D

Best of luck, and thanks again!

[9names]

My problem was a wiring issue, nothing to see here :facepalm: