Skip to content

Widget scroll#5938

Open
GuillaumeLescure wants to merge 1 commit intofyne-io:developfrom
GuillaumeLescure:widget-scroll
Open

Widget scroll#5938
GuillaumeLescure wants to merge 1 commit intofyne-io:developfrom
GuillaumeLescure:widget-scroll

Conversation

@GuillaumeLescure
Copy link
Copy Markdown

@GuillaumeLescure GuillaumeLescure commented Sep 7, 2025

Description:

The container.Scroll has a performance pitfall because it render every widgets even thoses that are not displayed.
The widget.Scroll solves that issue.

This PR is in WIP.
This is a prototype that demonstrates the design, I intend to improve it it with any given help.
There is still some issues with embedded containers (I can work on it) and the performances aren't as good as hoped (some help is welcome here).
It's my first PR for Fyne so I'm pretty sure there is still some work to do on my PR and it souldn't be pushed as it is.

Fixes #5914

Checklist:

  • Tests included.
  • Lint and formatter run with no errors.
  • Tests all pass.

Where applicable:

  • Public APIs match existing style and have Since: line.
  • Check for binary size increases when importing new modules.
@GuillaumeLescure
Add the widget.Scroll as a new collection widget.
e5a6db5 
WIP, still some issues to work on :
 - bug with embedded containers
 - performances seem a little off (it's better but not as much as I hoped)
 - comments to add (I will do when all other issues are resolved)

The widget.Scroll is like a container.Scroll but it only refresh the
displayed widget instead of all widget. Thus, it performs better than
its counterpart if many widgets are added.
@GuillaumeLescure GuillaumeLescure mentioned this pull request Sep 7, 2025
Open
2 tasks
@Jacalz Jacalz changed the base branch from master to develop September 7, 2025 17:35
Jacalz
Jacalz reviewed Sep 8, 2025
View reviewed changes
Copy link
Copy Markdown
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. The scroller that we are using is already a widget so would it not make sense to try and improve the performance of that instead of adding a new scrolling widget?

FYI: I would recommend making this "draft" while it is WIP.
@andydotxyz
Copy link
Copy Markdown
Member

andydotxyz commented Sep 10, 2025

I don't really understand what this is doing - but it seems to have some assumptions that don't hold:

a) A scroll can never change it's available directions
b) Apps don't need to control scroll position (i.e. messaging apps that always default to the bottom of the scroll)
c) a Container only has 1 root item

It is unclear why you are treating a container as a special case.

If you can explain the /how/ of the new optimised scroll that doesnt have to know child sizes then it might help us to offer suggestions.

There is still some issues with embedded containers (I can work on it) and the performances aren't as good as hoped (some help is welcome here).

As mentioned above please explain what the strategy is otherwise it's hard to say why performance is not what you'd expect.
Scrolling is hard and most times the only way to know the size of a child is to ask it (which requires renderer initiation).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants

@GuillaumeLescure @andydotxyz @Jacalz