Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a "Forced Scale" legacy fix for SurfaceView on older devices, refactoring the scaling logic in ProjectionViewScaler and updating AapProjectionActivity and ProjectionView to support this mode. Review feedback indicates that the stretchToFill logic is currently inverted in both ProjectionView and ProjectionViewScaler, leading to behavior opposite to the user's selection. Additionally, suggestions were made to use simple class names for imported types to improve readability and to optimize performance by avoiding redundant layout passes when updating view parameters.
app/src/main/java/com/andrerinas/headunitrevived/view/ProjectionViewScaler.kt
Show resolved
Hide resolved
app/src/main/java/com/andrerinas/headunitrevived/aap/AapProjectionActivity.kt
Outdated
Show resolved
Hide resolved
app/src/main/java/com/andrerinas/headunitrevived/aap/AapProjectionActivity.kt
Outdated
Show resolved
Hide resolved
| if (lp is FrameLayout.LayoutParams) { | ||
| lp.gravity = Gravity.CENTER | ||
| } | ||
| view.layoutParams = lp |
There was a problem hiding this comment.
Assigning layoutParams back to the view unconditionally triggers a layout pass (requestLayout()). Since updateScale is called during surface and size changes, this can lead to redundant layout cycles. It is recommended to check if the width, height, or gravity have actually changed before re-assigning the layout parameters. This applies to lines 54 and 76 as well.
1 participant
Added a new option for surfaceview which forced scale like HUR 7.2.2 and above. This should finally fix wrong surfaceview on older devices.