New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 905695 link

Starred by 1 user

Issue metadata

Status: Duplicate
Owner:
Closed: Nov 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature



Sign in to add a comment

Add support for hardware overlays/underlays at different screen resolutions

Project Member Reported by hadrosaur@google.com, Nov 15

Issue description

Chrome OS Version: <= M72
Chrome OS Platform: Google Pixelbook

Steps To Reproduce:
(1) Go to chrome://flags and turn on GL tinting
(2) Use an Android app that takes advantage of HW overlays/underlays at normal 100% resolution like Concepts or Infinite Painter. Notice #1
(3) Go to chrome settings->Display and decrease size toward "tiny" a little bit or increase it toward "huge".
(4) Try the android app again, notice #2

Results:
#1 - HW overlays/underlays are used. Drawing surface is not tinted, low-latency drawing is observed
#2 - HW overlays/underlays are not used. Entire app is tinted red, higher latency drawing is observed

How frequently does this problem reproduce? Always

What is the impact to the user, and is there a workaround? If so, what is it? The impact to heavy users of low latency drawing apps is that they must run their systems at the default resolution to get the lowest latency. This is not obvious to many users so they will experience this as poorer app experiences.

This may lead to poor reviews/press for apps and Chrome OS devices as it is inconsistent with expectations (apps should behave the same regardless of resolution).
 
Summary: Add support for hardware overlays/underlays at different screen resolutions (was: Add support for hardware overlays/underlays at difference scale factors)
Follow up question is: is there any way for Android apps running on Chrome OS to detect the Chrome OS resolution settings?
Mergedinto: 772419
Status: Duplicate (was: Unconfirmed)
issue 772419 is about [Zero latency] Support low-latency at non-default resolutions
which is not necessarily the same as having no hardware support for overlays / underlays only at 100%. If the two are related, this one is the stronger one as it affects many more applications.
skuhne: HW overlays logic doesn't know about "screen resolutions" and supports scaling when possible.

The problem is that buffers and contents are scaled when a user changes "screen resolutions". In particular ARC++ buffers seem not to be resized to the new resolution.

Scaling support for planes depends on the Hardware and sometimes we can't promote buffers to HW overlays for specific scaling factors.
The only way we have to maximize chances buffers will end up to HW overlays is to make sure contents coming via exo match screen space.

Sign in to add a comment