Question: How to clear a region after calling remove_element?

[Vanna DiCatania]

Is there a 'best way' to clear the drawn elements on the screen without a full redraw?

So far, I've tried:

1. app.get_framebuffer_ref().partial_refresh(...)
2. app.draw_element(&name)
3. app.clear(false); app.draw_elements();

the only one that seems to be close to the desired effect is 3, and it causes a visual-nasty full-screen redraw. What's the recommended approach to a ... partial clear and redraw?

IMO: this should look something like:

fn on_hide(app: &mut appctx::ApplicationContext<'_>, element: UIElementHandle) {
    let region: mxcfb_rect = element.read().last_drawn_rect.unwrap();
    app.remove_element("button".to_owned());
    app.clear(&region);
}

🤔

[Vanna DiCatania]

let rect = app
    .get_element_by_name("button")
    .unwrap()
    .read()
    .last_drawn_rect
    .unwrap();

app.remove_element("button");

println!(
    "Refreshing area {{ left:{}, top:{}, width:{}, height:{} }}.",
    rect.left, rect.top, rect.width, rect.height
);

app.get_framebuffer_ref().partial_refresh(
    &rect,
    PartialRefreshMode::Async,
    waveform_mode::WAVEFORM_MODE_GC16_FAST,
    display_temp::TEMP_USE_REMARKABLE_DRAW,
    dither_mode::EPDC_FLAG_USE_REMARKABLE_DITHER,
    DRAWING_QUANT_BIT,
    true,
);

Which prints

Refreshing area { left:1168, top:58, width:32, height:32 }.

But the previously drawn visuals are still present. The regions are no longer active, I can't interact with them, but they are still very much visible ... not just vague artifacts.

[Pierre Fenoll]

If you're drawing lines (and I believe you are) then try drawing the same lines but using the background color (or white). This should be pretty fast with async partial_refresh. Maybe make the lines "fatter" so as to account for potential artifacts.

[Vanna DiCatania]

Thanks, @fenollp! I don't love that as a solution, but it's a solid workaround as long as the new white lines don't start causing artifacts over other elements. RmKit doesn't seem to have this issue. I wonder if a technique in their drawing routines makes this a non-issue for them and their apps. I might explore that later if no one else gets to it first.

[Ben Kirwin]

One thing worth mentioning is: AFAICT, none of the published libremarkable apps (aside from the demo) use the built-in appctx stuff, instead preferring to implement their own UI layer. There's been some discussion of how to improve appctx, but it turns out to be tricky to find a set of primitives that can support both stuff like retris and folly using the same widgets.

If you don't like some appctx behaviour, all of the features of the library should be usable without it. Alternatively, if you have some clear idea for improving it that doesn't radically change behaviour, we'd likely be very receptive to a PR!