Question: How to clear a region after calling remove_element?
VannaDii opened this issue · comments
Is there a 'best way' to clear the drawn elements on the screen without a full redraw?
So far, I've tried:
app.get_framebuffer_ref().partial_refresh(...)
app.draw_element(&name)
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(®ion);
}
🤔
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.
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.
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.
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!