Bug #97144
closedSlow module scrolling in Google Chrome on Linux
100%
Description
Scrolling the list module with 100 entries causes FPS to drop to <15fps on Google Chrome (v99) with Linux during scrolling.
This is for sure a Chrome Bug, but reveals that overflow: hidden
and scrolling="no"
on the module iframe is not a good idea.
It would be great to remove the scrolling="no"
parameter from the module iframe and enable scrolling on <html> instead of .module-body
There are some past issues to take into account when changing the module-scrolling semantics: #83841 #80116 #82780
Using overflow: auto on <html>
as suggested in https://forge.typo3.org/issues/80116#note-7 was mainly avoided because of mobile iOS overscroll behaviour, otherwise this could have already been changed with: https://review.typo3.org/c/Packages/TYPO3.CMS/+/55647
Consider using the standardized overscroll-behaviour
property to fix issues on that part.
Files
Updated by Benjamin Franzke over 2 years ago
- Related to Bug #83841: Correct horizontal scrolling in iOS browsers added
Updated by Benjamin Franzke over 2 years ago
- Related to Bug #80116: rte_ckeditor displaces dropdown overlays and jumps to top of page on crome/safari added
Updated by Benjamin Franzke over 2 years ago
- Related to Bug #82780: RTE CKeditor top-positioning for maximize and combopanels is broken in browsers with webkit added
Updated by Benjamin Franzke over 2 years ago
- Subject changed from Slow module scrolling in Google Chrome on LInux to Slow module scrolling in Google Chrome on Linux
Updated by Benjamin Franzke over 2 years ago
Note that transform: translate3d(0,0,0)
applied to .module-body
"fixes" the issue as well.
(Also other 3d-offloading hacks like will-change: transform;
or transform: translateZ(0);
)
To reproduce the issue, the "Rendering" Tab of the Google Chrome inspector may be enabled and the checkbox "Paint flashing" checked.
Without the fix, all table entries are re-rendered on every scroll operation.
Updated by Benjamin Franzke over 2 years ago
Just noticed that this doesn't happen on my notebook with same software versions, only difference: 200% scaling because of HighDPI screen.
Now things get interesting, I found the following statement on https://dzone.com/articles/front-end-performance-optimization-with-accelerate
On a screen with the high DPI, fixed elements get automatically upgraded to the Compositing Layer. However, this is not applicable to devices with the low DPI because the PaintLayer upgrade changes the font rendering mode from sub-pixel to gray-scale. (For more information, see Text Rendering.)
So we have different rendering modes based on the OS-scaling mode.
And this let me to the following bug report:
https://bugs.chromium.org/p/chromium/issues/detail?id=597678#c3
This is because we don't promote the scrolling content to a compositor layer due to being low-DPI (and thus losing LCD text antialiasing). You can force this into a compositor layer by applying a transform on the scroller:
transform: translateZ(0)
This fixes the performance issue but may degrade text quality on lowDPI devices.
So transform: translateZ(0)
isn't a proper idea as well (we should rather enable html-based scrolling).
but reading the merged issue https://bugs.chromium.org/p/chromium/issues/detail?id=381840#c51 I figure the issue is related to the detection whether a scrollable element may be opaque or transparent and therefore needs possible composition with the underlaying elements.
So I figured another (non-intrusive workaround, that doesn't affect font-rendering): background-color: white
on .module-body.
Maybe that is a fix that would be suitable for v11 and v10 backports.
will do some more analysis…
Updated by Benjamin Franzke over 2 years ago
- TYPO3 Version changed from 11 to 10
Updated by Benjamin Franzke over 2 years ago
Can be easily reproduced in TYPO3 v10 by adding 100 records to a table:
for i in {1..100}; do mysql -Bse "insert into sys_news (title) values ('dummy');" db done
Chrome paint flash demo added as attachment.
Updated by Gerrit Code Review over 2 years ago
- Status changed from New to Under Review
Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74528
Updated by Benjamin Franzke over 2 years ago
See attachment for fixed performance (much improve paint reflash).
Updated by Benjamin Franzke over 2 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 8006093256a60bc401a45076ff50f459aa5fc423.
Updated by Christian Kuhn over 2 years ago
- Related to Bug #97713: EXT:dashboard's module-body background-color is overwritten by backend.css added