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:
- one is the background attached to the <body>. You see this one in the first two examples; in the second you modified to repaint much faster when scrolling (but this also changed the visual appearance, I'll come to this later).
- a sap.m.App control (and SplitApp and Shell) uses the full window size and brings its own background (which is on top of the one described above).So as soon as you use an App control (and you probably did so when wrapping the cards into a Page control), you are seeing a different background (which just looks identical). Your change to the background "in the background" doesn't have any effect now.
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:
- The background stretches to the height of the page content. So the gradient changes brightness rapidly on short pages and cannot be even recognized as gradient when looking at very long pages without scrolling: you only see the bright uppermost part, or the dark bottom part, or something in between. You only see a fraction of the gradient at a time. Navigation between pages of different size may then also mean that you slide from a dark bottom part of one page to a bright top part of another page.
- The background moves when scrolling. It's obvious - this is exactly your change. But it makes a difference to the eye. It gives more of a technically "clever" impression when not everything moves the same speed. I'm not saying a fixed background looks better, but, well, it might indeed look more appealing to some. Remember how parallax scrolling is also often used as means to make something look "nicer".
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.