Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug Causes Frame Inside of ScrollArea to Extend Beyond ScrollArea #1621

Open
newcomb-luke opened this issue May 11, 2022 · 4 comments
Open
Labels
bug Something is broken

Comments

@newcomb-luke
Copy link
Contributor

Describe the bug

The bug seems to come from adding a Frame to the inside of a ScrollArea. The bug is that when the ScrollArea has not been scrolled, everything appears as expected, but when you scroll down, the contents of the ScrollArea shift upwards by a small amount so that they extend slightly past where the ScrollArea is:

Scrolled to the top:
image

Scrolled down at all:
image

It may be difficult to see, but this is a zoomed-in version of the second picture:
image

To Reproduce
Steps to reproduce the behavior:

  1. Create any ScrollArea
  2. Inside of the ScrollArea, place a Frame
  3. Make the frame contain widgets large enough to cause the ScrollArea to need a scroll bar
  4. Scroll down

Expected behavior
The expected behavior would be that it displays in the correct bounds of the ScrollArea, just like it does when you are scrolled to the top.

Desktop:

  • OS: Arch Linux
  • Native App

I'm not sure if this is a bug in ScrollArea, or Frame somehow. Maybe both somehow.

@newcomb-luke newcomb-luke added the bug Something is broken label May 11, 2022
@newcomb-luke
Copy link
Contributor Author

I'm not sure how much this means or if it would help at all, but when I store the response from the ScrollArea, when I scroll, the response.inner_rect doesn't change when I scroll or if it is unscrolled:

image

@143mailliw
Copy link

It's almost certainly not a bug with the frame, as I was able to reproduce this with a textarea with no frame behind it - the text goes over.

@j-n-f
Copy link

j-n-f commented Jun 6, 2024

I've run into this same issue. Code and screenshots provided below.

Expand Code

Cargo.toml

[package]
name = "egui-1621-repro"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
eframe = { version = "0.27" }

main.rs

use eframe::{egui::{vec2, Color32, Sense, Stroke, ViewportBuilder}, App};

struct DemoApp;

impl App for DemoApp {
    fn update(&mut self, ctx: &eframe::egui::Context, frame: &mut eframe::Frame) {
        eframe::egui::CentralPanel::default()
            .show(ctx, |ui| {
                ui.spacing_mut().item_spacing = ui.spacing().item_spacing * 2.0;

                // Makes it easier to see what's up
                ui.horizontal(|ui| {
                    let zoom_levels = [1.0, 2.0, 4.0];
                    let current_level = ctx.pixels_per_point();
                    for level in zoom_levels.iter() {
                        let mut button = ui.button(format!("zoom {}", level));
                        if *level == current_level {
                            button = button.highlight();
                        }
                        if button.clicked() {
                            ctx.set_pixels_per_point(*level);
                        }
                    }
                });

                // Change scroll area styles to make bug extremely obvious
                let scroll = &mut ui.spacing_mut().scroll;
                scroll.floating = false;
                scroll.bar_width = 16.0;
                scroll.bar_inner_margin = 0.0;
                scroll.bar_outer_margin = 0.0;
                let visuals = &mut ui.visuals_mut();
                let widgets = &mut visuals.widgets;
                visuals.extreme_bg_color = Color32::GREEN.additive();
                widgets.inactive.rounding = 0.0.into();
                widgets.inactive.fg_stroke = Stroke::new(0.0, Color32::BLUE.additive()); // change stroke because this is where handle color comes from
                widgets.active.rounding = 0.0.into();
                widgets.active.fg_stroke = Stroke::new(0.0, Color32::BLUE.additive());
                widgets.hovered.rounding = 0.0.into();
                widgets.hovered.fg_stroke = Stroke::new(0.0, Color32::BLUE.additive());

                eframe::egui::containers::ScrollArea::both()
                    .show(ui, |ui| {
                        let (rect, rsp) = ui.allocate_exact_size(vec2(2048., 2048.), Sense::click());
                        ui.painter().rect_filled(rect, 0.0, Color32::RED);
                    })
            });
    }
}

fn main() {
    let native_options = eframe::NativeOptions {
        viewport: ViewportBuilder::default()
            .with_inner_size((1024., 768.)),
        ..Default::default()
    };

    let _ = eframe::run_native(
        "issue 1621",
        native_options,
        Box::new(|cc| {
            cc.egui_ctx.set_pixels_per_point(2.0);
            Box::new(DemoApp)
        })
    );
}

Illustrative screenshots

  • Scroll content is red
  • Scrollbar track is green
  • Scroll handles are blue
  • Colors are in additive mode to make overlaps/overflows more obvious

top-left

  • Scrollbars overlap content (white and yellow)
  • Leakage in bottom-right (red)

image

mid-left

  • Same as above, but now content is leaking above scroll area (red)

image

bottom-left

  • Leakage at bottom disappears, but leakage at top remains (red)

image

top-mid

  • Similar to y-axis behavior, scroll area leaks at left instead of top (red)

image

top-right

  • Similar to bottom-left, the red leakage in the bottom right corner disappears

image

Other notes

It looks like behavior changes at 4.0x zoom (you can try 8.0x as well and it becomes more obvious). At these zoom levels the right-side scrollbar will start to go above/below the extents of the track/background (probably easier to see with a white background, but still visible in dark mode)

#3734 is probably related.

@j-n-f
Copy link

j-n-f commented Jun 10, 2024

Also related #3385

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is broken
Projects
None yet
Development

No branches or pull requests

3 participants