Project

General

Profile

Actions

Bug #97144

closed

Slow module scrolling in Google Chrome on Linux

Added by Benjamin Franzke about 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Should have
Category:
-
Start date:
2022-03-08
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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

typo3v10-slow-scroll.webm (2.46 MB) typo3v10-slow-scroll.webm Benjamin Franzke, 2022-05-05 16:06
typo310-composited-scroll.webm (3.87 MB) typo310-composited-scroll.webm Benjamin Franzke, 2022-05-05 16:19

Related issues 4 (0 open4 closed)

Related to TYPO3 Core - Bug #83841: Correct horizontal scrolling in iOS browsersClosed2018-02-10

Actions
Related to TYPO3 Core - Bug #80116: rte_ckeditor displaces dropdown overlays and jumps to top of page on crome/safariClosedBenni Mack2017-03-03

Actions
Related to TYPO3 Core - Bug #82780: RTE CKeditor top-positioning for maximize and combopanels is broken in browsers with webkitClosed2017-10-17

Actions
Related to TYPO3 Core - Bug #97713: EXT:dashboard's module-body background-color is overwritten by backend.cssClosed2022-05-31

Actions
Actions #1

Updated by Benjamin Franzke about 2 years ago

  • Related to Bug #83841: Correct horizontal scrolling in iOS browsers added
Actions #2

Updated by Benjamin Franzke about 2 years ago

  • Related to Bug #80116: rte_ckeditor displaces dropdown overlays and jumps to top of page on crome/safari added
Actions #3

Updated by Benjamin Franzke about 2 years ago

  • Related to Bug #82780: RTE CKeditor top-positioning for maximize and combopanels is broken in browsers with webkit added
Actions #4

Updated by Benjamin Franzke about 2 years ago

  • Subject changed from Slow module scrolling in Google Chrome on LInux to Slow module scrolling in Google Chrome on Linux
Actions #5

Updated by Benjamin Franzke about 2 years ago

  • Description updated (diff)
Actions #6

Updated by Benjamin Franzke about 2 years ago

  • Description updated (diff)
Actions #7

Updated by Benjamin Franzke about 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.

Actions #8

Updated by Benjamin Franzke about 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…

Actions #9

Updated by Benjamin Franzke almost 2 years ago

  • TYPO3 Version changed from 11 to 10
Actions #10

Updated by Benjamin Franzke almost 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.

Actions #11

Updated by Gerrit Code Review almost 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

Actions #12

Updated by Benjamin Franzke almost 2 years ago

See attachment for fixed performance (much improve paint reflash).

Actions #13

Updated by Benjamin Franzke almost 2 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #14

Updated by Christian Kuhn almost 2 years ago

  • Related to Bug #97713: EXT:dashboard's module-body background-color is overwritten by backend.css added
Actions #15

Updated by Benni Mack over 1 year ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF