Scrolling stutters on 120Hz screens

[wiviwol947]

wiviwol947 last edited by

@mrxyzl this occurred previously. Drama Mini uses Chrome Android WebView yet in this way can't interface straightforwardly.

Next test, attempt Google chrome, does it stammer like Opera Mini or googles chrome falter like Opera full program.

In the past when Google began stammering in the long run Opera full program did on the grounds that Google Chrome and Opera full are from same code base an open source project.

Kindly let me know.

In the interim recurrent the test before 120 hz and after 60hz in telephone show choices.

On the off chance that 60hz showcase choice didn't work read this:

https://forums.opera.com/subject/29626/terrible looking over

Desire to hear from you. This occurred previously.

[A Former User]

A Former User @wiviwol947 last edited by

@wiviwol947 All Chromium based browsers now have this bug. That's a lot of them.

Here is an excellent example at the open source chromium development website.

https://bugs.chromium.org/p/chromium/issues/detail?id=1057459

They have included a good example video. But as you read some browsers have the flags that only one of needs to be set to disabled and it suddenly works smooth as it should.

Probably someone needs to forward it to the chromium development website too.

The reason they say flags disappeared is because after a certain amount of time a flag is disabled automatically in the building process.

[cherenok]

cherenok last edited by

I am also asking for this feature. I bought a phone (Xiaomi Mi 9T Pro) with DC dimming specifically so that my eyes don't hurt from PWM. But I can't use my favorite browser due to poor rendering performance. According to testufo.com , the frame rate was lowered to 40-43. If I temporarily disable DC dimming, the refresh rate will increase to 60. This can be fixed by disabling the "Use Android Surface Control" option (works in Chrome, Brave and Vivaldi). I really hope that you, dear developers, will not pass by our problem.

[A Former User]

A Former User @cherenok last edited by

@cherenok I tried chrome, brave, vivaldi and they all worked fluently only after setting the surface flag to disabled. Without it those browsers are pretty useless. Samsung internet doesn't have flags and firefox has no flags in release but has in developer preview. This is really bad. A simple tiny switch can make a browser utterly unfunctional. And guess which browser all these years was never affected? It starts with an S and ends with ...sung.

[miyukiwork]

miyukiwork Opera @Japs last edited by

@japs

Hello! We are investigating this issue and would like to know where exactly we can observe the problem. If it happens in the webpage area, please specify which website is loaded even though it happens on every site. If it happens in UI, where and which action is not smooth?

[Mrxyzl]

Mrxyzl @miyukiwork last edited by Mrxyzl

@miyukiwork
Hello, first, i want to thanks the team for investigate this issue
I have stuttering when scrolling on this site, especially at the end of a fling, it seem to skip a few frame. The issue is more noticeable on android 11.
My phone is S21+ Exynos on oneui 3.1 android 11. Android 12 seem to have less stuttering

Edit: another site i notice extreme stuttering is this one

[Japs]

Japs @miyukiwork last edited by

@miyukiwork

Hello,

Thank you for responding. The issue happens on pretty much every webpage (not the Opera UI). It certainly happens for example on https://www.thurrott.com/# and on https://www.androidcentral.com/blog. It occurs every time I scroll on these pages (and is particularly obvious with a "real" scroll, i.e when you swipe with your finger and then lift your finger).

I hope you will be able to fix this very soon.

[personal1985 0]

personal1985 0 @miyukiwork last edited by

@miyukiwork every website including Wikipedia. The fix for this is already posted for all chromium based browsers but Opera is the only browser which has no flags anymore.

Tested with Chrome, Vivaldi and Brave, all chromium based too, identical behavior until setting the flag.

Example to get Chrome working:

Chrome before switching flag has identical stutter behavior.

Then in chrome://flags disabling the "Android SurfaceControl"

Chrome now suddenly is very smooth in scrolling.

https://bugs.chromium.org/p/chromium/issues/detail?id=1057459

A tiny switch and Opera would have been smooth too.

[miyukiwork]

miyukiwork Opera @Japs last edited by

@japs

Yes, now we can see the problem especially in https://www.thurrott.com/#
Thanks a lot for the info!

[miyukiwork]

miyukiwork Opera @miyukiwork last edited by

The latest beta version 67.0.3485.62523 includes "Android SurfaceControl" in opera://flags

[Japs]

Japs @miyukiwork last edited by

@miyukiwork Thanks for the follow-up! I just briefly tested the beta version, switching between surfacecontrol enabled and disabled, but I unfortunately don't seem to notice any difference I must say.

[cherenok]

cherenok @miyukiwork last edited by

@miyukiwork I tested the update and can say it works great with enable DC dimming. I don't see any stutter in the picture. The site testufo.com shows 60 fps. I am completely satisfied. Thanks for your work.

[A Former User]

A Former User @miyukiwork last edited by

@miyukiwork it works and is fluently scrolling in last beta after setting flag as disabled. As far as I know only Android 10 and later devices are affected. Hopefully this reaches normal version too.

Tab s5e Android 11 needs this flag disabled. WORKS!
Galaxy S8 Android 9 does not use this flag, since it's android 10 or later that are affected.

Thanks for your team.

[A Former User]

A Former User @Guest last edited by A Former User

@ginger1984 good news considering battery usage. It's the same as other browsers, in my case 10,2 % per hour of screen on browsing. Only it's fluently now. This reply is added to see if side effects were existing.
(Galaxy tab s5e android 11)

[A Former User]

A Former User @Guest last edited by leocg

Officially fixed by disabling the "Android SurfaceControl" flag for Android 10 or higher in opera://flags

It's available in beta and official release now.

Besides that it works I actually wonder what Android SurfaceControl was supposed to do in chromium based browsers and why so many browsers had this problem.

Only people knowing how to access the flag for example now understand how to fix.

It's 7 months and even google themselves didn't fix it but here is technically info of the API introduction in Android 10

Android Open Source Project
Docs
GO TO CODE ➚
Search

Language
Aanmelden
DOCUMENTATION
Getting Started
Security
Core Topics
Compatibility
Android Devices
Reference
Filter

AOSP
Docs
Core Topics
Was this helpful?

Send feedbackSurfaceFlinger and WindowManager 
SurfaceFlinger accepts buffers, composes buffers, and sends buffers to the display. WindowManager provides SurfaceFlinger with buffers and window metadata, which SurfaceFlinger uses to composite surfaces to the display.

SurfaceFlinger
SurfaceFlinger can accept buffers in two ways: through BufferQueue and SurfaceControl, or through ASurfaceControl.

One way SurfaceFlinger accepts buffers is through BufferQueue and SurfaceControl. When an app comes to the foreground, it requests buffers from WindowManager. WindowManager then requests a layer from SurfaceFlinger. A layer is a combination of a surface, which contains the BufferQueue, and a SurfaceControl, which contains the layer metadata like the display frame. SurfaceFlinger creates the layer and sends it to WindowManager. WindowManager then sends the surface to the app, but keeps the SurfaceControl to manipulate the appearance of the app on the screen.

Android 10 adds ASurfaceControl, which is another way that SurfaceFlinger can accept buffers. ASurfaceControl combines a surface and a SurfaceControl into one transaction package that is sent to SurfaceFlinger. An ASurfaceControl is associated with a layer, which apps update through ASurfaceTransactions. Apps then get information about ASurfaceTransactions through callbacks that pass ASurfaceTransactionStats containing information, such as latch time, acquire times, and so on.

Android Open Source Project
Docs
GO TO CODE ➚
Search

Language
Aanmelden
DOCUMENTATION
Getting Started
Security
Core Topics
Compatibility
Android Devices
Reference
Filter

AOSP
Docs
Core Topics
Was this helpful?

Send feedbackSurfaceFlinger and WindowManager 
SurfaceFlinger accepts buffers, composes buffers, and sends buffers to the display. WindowManager provides SurfaceFlinger with buffers and window metadata, which SurfaceFlinger uses to composite surfaces to the display.

SurfaceFlinger
SurfaceFlinger can accept buffers in two ways: through BufferQueue and SurfaceControl, or through ASurfaceControl.

One way SurfaceFlinger accepts buffers is through BufferQueue and SurfaceControl. When an app comes to the foreground, it requests buffers from WindowManager. WindowManager then requests a layer from SurfaceFlinger. A layer is a combination of a surface, which contains the BufferQueue, and a SurfaceControl, which contains the layer metadata like the display frame. SurfaceFlinger creates the layer and sends it to WindowManager. WindowManager then sends the surface to the app, but keeps the SurfaceControl to manipulate the appearance of the app on the screen.

Android 10 adds ASurfaceControl, which is another way that SurfaceFlinger can accept buffers. ASurfaceControl combines a surface and a SurfaceControl into one transaction package that is sent to SurfaceFlinger. An ASurfaceControl is associated with a layer, which apps update through ASurfaceTransactions. Apps then get information about ASurfaceTransactions through callbacks that pass ASurfaceTransactionStats containing information, such as latch time, acquire times, and so on.

The following table includes more details about ASurfaceControl and its associated components.

Component	Description
ASurfaceControl	Wraps SurfaceControl and enables an app to create SurfaceControls that correspond to layers on the display.

Can be created as a child of ANativeWindow or as a child of another ASurfaceControl.
ASurfaceTransaction	Wraps Transaction to enable the client to edit a layer's descriptive properties, such as geometry, and sends the updated buffers to SurfaceFlinger.
ASurfaceTransactionStats	Sends information about transactions that have been presented, such as latch time, acquire times, and previous release fence, to an app through a preregistered callback.
Though apps can submit buffers at any time, SurfaceFlinger only wakes up to accept buffers between display refreshes, which can differ depending on the device. This minimizes memory usage and avoids visible tearing on the screen, which can occur when updating the display mid-refresh.

When the display is between refreshes, the display sends the VSYNC signal to SurfaceFlinger. The VSYNC signal indicates that the display can be refreshed without tearing. When SurfaceFlinger receives the VSYNC signal, SurfaceFlinger walks through its list of layers looking for new buffers. If SurfaceFlinger finds a new buffer, SurfaceFlinger acquires the buffer; if not, SurfaceFlinger continues to use the previously acquired buffer. SurfaceFlinger must always display something, so it hangs on to one buffer. If no buffers have ever been submitted on a layer, the layer is ignored.

After SurfaceFlinger has collected all buffers for visible layers, it asks the Hardware Composer (HWC) how composition should be performed. If the HWC marks layer composition type as client composition, SurfaceFlinger composites those layers. Then, SurfaceFlinger passes the output buffer to the HWC.

Android Open Source Project
Docs
GO TO CODE ➚
Search

Language
Aanmelden
DOCUMENTATION
Getting Started
Security
Core Topics
Compatibility
Android Devices
Reference
Filter

AOSP
Docs
Core Topics
Was this helpful?

Send feedbackSurfaceFlinger and WindowManager 
SurfaceFlinger accepts buffers, composes buffers, and sends buffers to the display. WindowManager provides SurfaceFlinger with buffers and window metadata, which SurfaceFlinger uses to composite surfaces to the display.

SurfaceFlinger
SurfaceFlinger can accept buffers in two ways: through BufferQueue and SurfaceControl, or through ASurfaceControl.

One way SurfaceFlinger accepts buffers is through BufferQueue and SurfaceControl. When an app comes to the foreground, it requests buffers from WindowManager. WindowManager then requests a layer from SurfaceFlinger. A layer is a combination of a surface, which contains the BufferQueue, and a SurfaceControl, which contains the layer metadata like the display frame. SurfaceFlinger creates the layer and sends it to WindowManager. WindowManager then sends the surface to the app, but keeps the SurfaceControl to manipulate the appearance of the app on the screen.

Android 10 adds ASurfaceControl, which is another way that SurfaceFlinger can accept buffers. ASurfaceControl combines a surface and a SurfaceControl into one transaction package that is sent to SurfaceFlinger. An ASurfaceControl is associated with a layer, which apps update through ASurfaceTransactions. Apps then get information about ASurfaceTransactions through callbacks that pass ASurfaceTransactionStats containing information, such as latch time, acquire times, and so on.

The following table includes more details about ASurfaceControl and its associated components.

Component	Description
ASurfaceControl	Wraps SurfaceControl and enables an app to create SurfaceControls that correspond to layers on the display.

Can be created as a child of ANativeWindow or as a child of another ASurfaceControl.
ASurfaceTransaction	Wraps Transaction to enable the client to edit a layer's descriptive properties, such as geometry, and sends the updated buffers to SurfaceFlinger.
ASurfaceTransactionStats	Sends information about transactions that have been presented, such as latch time, acquire times, and previous release fence, to an app through a preregistered callback.
Though apps can submit buffers at any time, SurfaceFlinger only wakes up to accept buffers between display refreshes, which can differ depending on the device. This minimizes memory usage and avoids visible tearing on the screen, which can occur when updating the display mid-refresh.

When the display is between refreshes, the display sends the VSYNC signal to SurfaceFlinger. The VSYNC signal indicates that the display can be refreshed without tearing. When SurfaceFlinger receives the VSYNC signal, SurfaceFlinger walks through its list of layers looking for new buffers. If SurfaceFlinger finds a new buffer, SurfaceFlinger acquires the buffer; if not, SurfaceFlinger continues to use the previously acquired buffer. SurfaceFlinger must always display something, so it hangs on to one buffer. If no buffers have ever been submitted on a layer, the layer is ignored.

After SurfaceFlinger has collected all buffers for visible layers, it asks the Hardware Composer (HWC) how composition should be performed. If the HWC marks layer composition type as client composition, SurfaceFlinger composites those layers. Then, SurfaceFlinger passes the output buffer to the HWC.

WindowManager
WindowManager controls window objects, which are containers for view objects. Window objects are always backed by surface objects. WindowManager oversees lifecycles, input and focus events, screen orientation, transitions, animations, position, transforms, z-order, and many other aspects of a window. WindowManager sends all of the window metadata to SurfaceFlinger so SurfaceFlinger can use that data to composite surfaces on the display.

Pre-rotation
Many hardware overlays don't support rotation (and even if they do, it costs processing power); the solution is to transform the buffer before it reaches SurfaceFlinger. Android supports a query hint (NATIVE_WINDOW_TRANSFORM_HINT) in ANativeWindow to represent the most likely transform to be applied to the buffer by SurfaceFlinger. GL drivers can use this hint to pre-transform the buffer before it reaches SurfaceFlinger so that when the buffer arrives, it's correctly transformed.

For example, when receiving a hint to rotate 90 degrees, generate and apply a matrix to the buffer to prevent it from running off the end of the page. To save power, do this pre-rotation. For details, see the ANativeWindow interface defined in system/core/include/system/window.h.`

[ervinj]

ervinj last edited by

I can confirm that Galaxy Tab s5e is also affected seriously unfortunately again with this bug.

Chrome before switching flag has identical stutter behavior.

Then in chrome://flags disabling the "Android SurfaceControl"

Chrome now suddenly is very smooth in scrolling.

Al Opera has to do is considering giving the flags options back as they existed in the past.

opera://flags

The biggest problem with Android is for me that it has continually regression in bugs, and these bugs you can wait for easily 2 years to be fixed.

I will try this fix in Chrome at my mobile phone to see if it has similar results since then more devices are affected.

Also a lot of phones like Xiomi seem to be affected when reading about this flag that proves just a tiny thing can make it work smoothly.

I don't like Chrome itself it has continually Microsoft office like digital assistant popping up which a lot of people knew as Clipy Office assistant.

Besides that nowadays when visiting a website it's pushing popup for cookies, selecting lists of cookies, floating ads while scrolling, then a lucky you win advertising, then subscribe to website then login button to read more, then finally reading an article, yes that is Google chrome, oh I forget Google says if I want to get automatic translation at every page...