Hi,
I'm working with a side project called openui5-cards and are experiencing some issues with scrolling performance. As far as I can see, the problems are general for sap.m.App and/or sap.m.Page and not specific for my components (therefore it should also affect all other sapui5 apps such as fiori)
I'm testing this on desktop chrome and android 4.4 chrome/webview, but I assume these issues are for all browser.
The goal is to have a 60 fps experience when scrolling which leave 16 ms pr frame to be rendered.
When the user is scrolling, it's essential that the whole screen is not repainted after a scroll event. If this happens, you will not be able to reach the 60 fps goal.
I've solved the issues when adding my custom components directly to a div, but am still experiencing issues when adding it to a sap.m.Page and sap.m.App. To reproduce the problems, I've three examples:
http://elsewhat.github.io/openui5-cards/cdn/0.1/example3-1perfissue.html
Here the open.m.CardContainer is added directly to the div (no sap.m.Page or sap.m.App).
This example suffers from full repaint when scrolling
http://elsewhat.github.io/openui5-cards/cdn/0.1/example3-2perfissue.html
Same as the above, but have added the following style:
body{
background-attachment:scroll;
}
The property background-attachment was set to value fixed by sapui5, but here we've overwritten it.
This example does not suffer from full repaint, and is working as we want
http://elsewhat.github.io/openui5-cards/cdn/0.1/example3-3perfissue.html
Same as above, but are adding the open.m.CardContainer to a sap.m.Page which is then added to a sap.m.App that is bound to the content div.
This example suffers from the full repaint when scrolling
(and is the one we want to solve)
To help you understand the video, I've created a short screenrecording showing the repaint issue more clearly. It uses the chrome dev tools timeline.
Improving performance with openui5 and sap.m.App and sap.m.Page - YouTube
Any ideas where to fix this issue ?
Hi Dagfinn,
yeah, this is better than the 140-characters-restricted Twitter attempt... so I can explain better what's happening. :-)
There are TWO backgrounds:
What was the original issue? When the background (the white stripes on blue gradient) are fixed, but the content is scrolled, in the browser's graphics realm there are two layers which are moved on top of each other, the upper layer being transparent in places (where there are no cards). Whenever the upper layer moves, different parts of the background gradient may become visible, so the browser has to redraw everything.
When the background moves together with the foreground, both merge into one graphics layer, which can be just moved around (this is quite cheap, even the old Atari STE had a special chip to make this kind of operation very fast). The browser only has to paint the tiny bits that are scrolled into view.
So this is the improvement you did between example one and two.
(I'm sure you know it, I just wanted to write it explicitly.)
Now in example 3 we are not looking at the same background. We are looking at a new background which looks the same, but is technically the background of one <div> that belongs to the App control and takes exactly 100% by 100% of the screen (the element with ID "__app0-BG"). This div does not scroll, so there is no need for "background-attachment: fixed in the CSS". The whole element is just statically sitting there.
But there is the Page control which now offers scrolling inside a certain sub-area of the screen (the <section> mentioned by Jason is the frame and its child element is the larger area which holds the content and is scrolled).
So from the perspective of the browser's graphics engine we have the same situation as in the first example: one layer which has the background pattern, and one layer with content moving over this background. Again two layers which need to be re-combined for every scroll step.
The easiest way to do your performance improvement on this level would be to apply the same background on the scrolled area - the element with ID "openui5-cards-scroll". This would make the background scroll together with the content, so the browser only has to paint the new areas during scrolling and can just move the rest.
However, the change you did also affected the visual appearance:
Of course when scrolling performance is totally bad, then it's much better to accept these two visual changes in favor of better performance, but especially on Chrome I didn't really notice scrolling to feel slow.
We really have to explicitly test this on weaker mobile devices, though. So of course thanks a lot for the hint!!!
There's another reason for fixing the background, by the way:
When a different background image is used, e.g. some vacation photo, or just a shadow of a company logo (can be easily done in Theme Designer), then it is not an option to stretch it to the height of the page!
You'd also not like to scroll up and down your vacation photo all the time or to see the feet of your son on one page and then his head on the next or so.
So with a background image which is more than just a pattern, fixing the background and limiting its size to the screen size is a "must".
Regards
Andreas
Interesting issue, on first glance I see the example 3-3 displays the page header which is full width, so it's scrolling an element rather than the whole page??
devtools has the option to show the repaint bottlenecks, just tried and it shows there is an issue for the 3-3 example.
Will have a better look later.
Jason
Hi,
I'm doing an app for mobile, and I'm facing a problem of scrolling from left to right. I can scroll up and down, but I can´t scroll left to right. As I can´t do the scroll I'm not able to see all the content of my page. Can anyone help me?
Thanks in advance,
Raissa Almeida
Add a comment