Feature request
Please add a public API that lets an application opt out of the on-scroll re-layout that was introduced to fix #12608. We understand this trades layout correctness for scrolling performance, and for our use case that is exactly the tradeoff we want to make.
Background
We upgraded a Grid-heavy view and observed significant client-side lag when scrolling vertically (horizontal scrolling is unaffected). After investigation we traced the regression to the fix for #12608 ("Grid renders incorrectly cells having Layout components").
As described in that issue, the fix hooks into Escalator's scroll event in GridConnector and schedules a re-layout on scroll. The maintainer noted this was a deliberate, fastest-to-deliver compromise with known overhead, and that a lower-overhead approach (partial re-layout of only the recycled rows) might be revisited later. The workaround is present from 8.25.0 onward; 8.24.0 does not have it.
We confirmed this empirically:
| Version |
Scroll performance |
| Vaadin 8.14.3 (plain Framework 8) |
OK |
| Vaadin 25.2.2 + MPR + Vaadin 8.31.1 |
Laggy on vertical scroll |
| Vaadin 25.2.2 + MPR + Vaadin 8.27.0 |
Laggy on vertical scroll |
| Vaadin 25.2.2 + MPR + Vaadin 8.24.0 |
OK (issue gone) |
Note: this is not an MPR-specific problem: the re-layout runs in the Framework 8 client code regardless of whether the view runs standalone or inside MPR. We only mention MPR because that is our current deployment context. Downgrading to 8.24.0 also required adding com.github.oshi:oshi-core:6.9.1 as an explicit dependency to make the app start, but that is unrelated to the scrolling behaviour.
Importantly, our cells do not exhibit the misalignment that #12608 fixed, so for us the re-layout is pure cost with no benefit. We would like to keep the latest 8.x line while disabling this specific workaround.
Environment
- Vaadin Framework: 8.31.1 (regression), 8.24.0 (unaffected baseline)
- Running under Vaadin 25.2.2 + MPR (also expected to reproduce on plain Framework 8 ≥ 8.25)
- Browser: Chrome (latest)
Why our Grid is affected
The affected view is a shift calendar:
- 100+ rows (one per employee)
- 32 columns (1 name column + 31 day columns)
- Each day column uses a
ComponentRenderer
- Each rendered cell is a
CssLayout containing a custom TextField (or a Label) plus a second CssLayout holding up to four Labels
Because Grid virtualizes rows but keeps all columns of a rendered row present, vertical scrolling recycles these fairly heavy component trees and triggers the scroll-driven re-layout for every column in every recycled row. With 32 component-rendered columns this adds up quickly.
We are already aware of the general performance guidance (fewer columns, fewer rendered components per cell, lighter renderers). Those help but don't address the specific overhead added by the #12608 fix, which is what this request is about.
Proposed solution
A way to disable the scroll-triggered re-layout, opting back into pre-8.25 behaviour. We don't have a preference on the exact shape, whatever fits the Framework's conventions. For example: A per-Grid setter, e.g. grid.setLayoutOnScrollEnabled(false) (default true to preserve current behaviour), or
Defaulting to the current behaviour so existing apps are unaffected, with an explicit opt-out for apps that don't hit the layout bug and prefer the better scroll performance.
Reproduction sketch
A Grid with several ComponentRenderer columns rendering nested layouts (see #12608's reproduction, scaled up in column and row count) is sufficient to observe the on-scroll cost. We can provide a minimal reproduction project on request.
Feature request
Please add a public API that lets an application opt out of the on-scroll re-layout that was introduced to fix #12608. We understand this trades layout correctness for scrolling performance, and for our use case that is exactly the tradeoff we want to make.
Background
We upgraded a Grid-heavy view and observed significant client-side lag when scrolling vertically (horizontal scrolling is unaffected). After investigation we traced the regression to the fix for #12608 ("Grid renders incorrectly cells having Layout components").
As described in that issue, the fix hooks into Escalator's scroll event in
GridConnectorand schedules a re-layout on scroll. The maintainer noted this was a deliberate, fastest-to-deliver compromise with known overhead, and that a lower-overhead approach (partial re-layout of only the recycled rows) might be revisited later. The workaround is present from 8.25.0 onward; 8.24.0 does not have it.We confirmed this empirically:
Note: this is not an MPR-specific problem: the re-layout runs in the Framework 8 client code regardless of whether the view runs standalone or inside MPR. We only mention MPR because that is our current deployment context. Downgrading to 8.24.0 also required adding
com.github.oshi:oshi-core:6.9.1as an explicit dependency to make the app start, but that is unrelated to the scrolling behaviour.Importantly, our cells do not exhibit the misalignment that #12608 fixed, so for us the re-layout is pure cost with no benefit. We would like to keep the latest 8.x line while disabling this specific workaround.
Environment
Why our Grid is affected
The affected view is a shift calendar:
ComponentRendererCssLayoutcontaining a customTextField(or aLabel) plus a secondCssLayoutholding up to fourLabelsBecause Grid virtualizes rows but keeps all columns of a rendered row present, vertical scrolling recycles these fairly heavy component trees and triggers the scroll-driven re-layout for every column in every recycled row. With 32 component-rendered columns this adds up quickly.
We are already aware of the general performance guidance (fewer columns, fewer rendered components per cell, lighter renderers). Those help but don't address the specific overhead added by the #12608 fix, which is what this request is about.
Proposed solution
A way to disable the scroll-triggered re-layout, opting back into pre-8.25 behaviour. We don't have a preference on the exact shape, whatever fits the Framework's conventions. For example: A per-
Gridsetter, e.g.grid.setLayoutOnScrollEnabled(false)(defaulttrueto preserve current behaviour), orDefaulting to the current behaviour so existing apps are unaffected, with an explicit opt-out for apps that don't hit the layout bug and prefer the better scroll performance.
Reproduction sketch
A Grid with several
ComponentRenderercolumns rendering nested layouts (see #12608's reproduction, scaled up in column and row count) is sufficient to observe the on-scroll cost. We can provide a minimal reproduction project on request.