ScrollArea contents briefly escape it when it becomes larger #4742

e00E · 2024-06-30T16:25:04Z

I have content inside a ScrollArea. When the content's size changes and goes from fitting into the area to no longer fitting, then for a split second the content escapes the ScrollArea. After the split second the content is correctly limited to the area and can be scrolled.

I would expect the content to not appear out of bounds for the split second. I realize there are some layout limitations with egui's design. I feel this is a bug because the available size of the area is known at all times. I do not see why in principle there has to be a moment (one frame?) of bad layout.

Below is a minimal reproduction. The program displays a label inside a fixed size scroll area. When it starts, the label fits and there is no need to scroll. When you click the button, the amount of text changes so that it no longer fits into the scroll area and scrolling is needed.

use eframe::Frame;
use egui::{Context, ScrollArea};

fn main() -> eframe::Result<()> {
    let mut lines: usize = 1;

    let run = move |c: &Context, _: &mut Frame| {
        let text = "aaaa\n".repeat(lines);

        egui::CentralPanel::default().show(c, |ui| {
            ui.horizontal(|ui| {
                ui.allocate_ui((50., 50.).into(), |ui| {
                    ScrollArea::both()
                        .auto_shrink(false)
                        .show(ui, |ui| ui.label(text));
                });

                if ui.button("button").clicked() {
                    if lines == 10 {
                        lines = 1;
                    } else {
                        lines = 10;
                    }
                };
            });
        });
    };

    let options = eframe::NativeOptions::default();
    eframe::run_simple_native("", options, run)
}

Here are screenshots displaying the bug.

Before you press the button. There is no bug.

After you press the button, for a split second you can see the bug. The text exceeds the area. If I had more content below, the text would be rendered on top of it.

After the split second. There is no bug.

emilk · 2024-06-30T19:57:47Z

This should ineed be fixable. The clip rect is probably not set correctly when the ScrollArea believes (based on sizes from previous frame) that it won't need to clip.

When a `ScrollArea` is added to a `Ui` or its contents change dynamically, the contents will briefly escape the container. This occurs because `ScrollArea` internally maintains `content_is_too_large` flags, from which it determines when to clip. The `content_is_too_large` flags are calculated after painting, so they always lag one frame behind. This can lead to flickering. To fix this, I have changed the `ScrollArea` so that it always clips scrollable content. I believe that this should fix things without negatively impacting other behavior. To see this, consider how `ScrollArea` calculates the `content_is_too_large` flag: ```rust // This calculates a new inner rect, after painting, from the initial clip rect let inner_rect = { // At this point this is the available size for the inner rect. let mut inner_size = inner_rect.size(); for d in 0..2 { inner_size[d] = match (scroll_enabled[d], auto_shrink[d]) { (true, true) => inner_size[d].min(content_size[d]), // shrink scroll area if content is small (true, false) => inner_size[d], // let scroll area be larger than content; fill with blank space (false, true) => content_size[d], // Follow the content (expand/contract to fit it). (false, false) => inner_size[d].max(content_size[d]), // Expand to fit content }; } Rect::from_min_size(inner_rect.min, inner_size) }; let outer_rect = Rect::from_min_size(inner_rect.min, inner_rect.size() + current_bar_use); let content_is_too_large = Vec2b::new( scroll_enabled[0] && inner_rect.width() < content_size.x, scroll_enabled[1] && inner_rect.height() < content_size.y, ); ``` If `scroll_enabled[d] == true`, then the actual `inner_rect` (which is calculated after painting contents) will always be smaller than the original `inner_rect`. Hence, it is safe to unconditionally clip the contents to `inner_rect` whenever `scroll_enabled[d] == true`.  * Closes <#4742> * [x] I have followed the instructions in the PR template

…k#5006) When a `ScrollArea` is added to a `Ui` or its contents change dynamically, the contents will briefly escape the container. This occurs because `ScrollArea` internally maintains `content_is_too_large` flags, from which it determines when to clip. The `content_is_too_large` flags are calculated after painting, so they always lag one frame behind. This can lead to flickering. To fix this, I have changed the `ScrollArea` so that it always clips scrollable content. I believe that this should fix things without negatively impacting other behavior. To see this, consider how `ScrollArea` calculates the `content_is_too_large` flag: ```rust // This calculates a new inner rect, after painting, from the initial clip rect let inner_rect = { // At this point this is the available size for the inner rect. let mut inner_size = inner_rect.size(); for d in 0..2 { inner_size[d] = match (scroll_enabled[d], auto_shrink[d]) { (true, true) => inner_size[d].min(content_size[d]), // shrink scroll area if content is small (true, false) => inner_size[d], // let scroll area be larger than content; fill with blank space (false, true) => content_size[d], // Follow the content (expand/contract to fit it). (false, false) => inner_size[d].max(content_size[d]), // Expand to fit content }; } Rect::from_min_size(inner_rect.min, inner_size) }; let outer_rect = Rect::from_min_size(inner_rect.min, inner_rect.size() + current_bar_use); let content_is_too_large = Vec2b::new( scroll_enabled[0] && inner_rect.width() < content_size.x, scroll_enabled[1] && inner_rect.height() < content_size.y, ); ``` If `scroll_enabled[d] == true`, then the actual `inner_rect` (which is calculated after painting contents) will always be smaller than the original `inner_rect`. Hence, it is safe to unconditionally clip the contents to `inner_rect` whenever `scroll_enabled[d] == true`.  * Closes <emilk#4742> * [x] I have followed the instructions in the PR template

e00E added the bug Something is broken label Jun 30, 2024

DouglasDwyer mentioned this issue Aug 26, 2024

Prevent ScrollArea contents from exceeding the container size #5006

Merged

1 task

emilk closed this as completed in #5006 Aug 27, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ScrollArea contents briefly escape it when it becomes larger #4742

ScrollArea contents briefly escape it when it becomes larger #4742

e00E commented Jun 30, 2024

emilk commented Jun 30, 2024

ScrollArea contents briefly escape it when it becomes larger #4742

ScrollArea contents briefly escape it when it becomes larger #4742

Comments

e00E commented Jun 30, 2024

emilk commented Jun 30, 2024