this post was submitted on 09 Nov 2024
48 points (98.0% liked)

Android

17671 readers
67 users here now

The new home of /r/Android on Lemmy and the Fediverse!

Android news, reviews, tips, and discussions about rooting, tutorials, and apps.

🔗Universal Link: !android@lemdro.id

💡Content Philosophy:

Content which benefits the community (news, rumours, and discussions) is generally allowed and is valued over content which benefits only the individual (technical questions, help buying/selling, rants, self-promotion, etc.) which will be removed if it's in violation of the rules.

Support, technical, or app related questions belong in: !askandroid@lemdro.id

For fresh communities, lemmy apps, and instance updates: !lemdroid@lemdro.id

💬Matrix Chat

💬Telegram channels / chats

📰Our communities below

Rules

  1. Stay on topic: All posts should be related to the Android OS or ecosystem.

  2. No support questions, recommendation requests, rants, or bug reports: Posts must benefit the community rather than the individual. Please post to !askandroid@lemdro.id.

  3. Describe images/videos, no memes: Please include a text description when sharing images or videos. Post memes to !androidmemes@lemdro.id.

  4. No self-promotion spam: Active community members can post their apps if they answer any questions in the comments. Please do not post links to your own website, YouTube, blog content, or communities.

  5. No reposts or rehosted content: Share only the original source of an article, unless it's not available in English or requires logging in (like Twitter). Avoid reposting the same topic from other sources.

  6. No editorializing titles: You can add the author or website's name if helpful, but keep article titles unchanged.

  7. No piracy or unverified APKs: Do not share links or direct people to pirated content or unverified APKs, which may contain malicious code.

  8. No unauthorized polls, bots, or giveaways: Do not create polls, use bots, or organize giveaways without first contacting mods for approval.

  9. No offensive or low-effort content: Don't post offensive or unhelpful content. Keep it civil and friendly!

  10. No affiliate links: Posting affiliate links is not allowed.

Quick Links

Our Communities

Lemmy App List

Chat and More

founded 1 year ago
MODERATORS
ijeff@lemdro.id
ladfrombrad@lemdro.id
Paradox@lemdro.id
multimoon@lemdro.id
mikestevens@lemdro.id
Devgard@lemmy.world
limerod@reddthat.com
Netrunner@lemdro.id
48
Android 15 finally implements true variable refresh rate support, but there's a catch (www.androidauthority.com)
submitted 3 days ago by limerod@reddthat.com to c/android@lemdro.id
6 comments fedilink hide all child comments
 

TL;DR

  • The adaptive refresh rate (ARR) feature in Android 15 enables the display refresh rate to adapt to the frame rate of content.
  • The ARR feature reduces power consumption and jank as it lets devices operate at lower refresh rates without the need for mode switching.
  • While previous versions of Android supported multiple refresh rates, they did so by switching between discrete display modes.
you are viewing a single comment's thread
view the rest of the comments
[–] bossjack@lemmy.world 10 points 3 days ago (1 children)

Android Authority 's TL;DR (conveniently) doesn't mention the actual downside to this update. But it's fine imo, since this was actually a pretty insightful read.

My TL;DR:

  • Google's ARR/VRR implementation is hopefully more compatible with the GKI system vs. current per-vendor, per-device implementations
  • To add this support, vendors must implement v3 of the Hardware Composer and Hardware Abstraction Layer APIs.
  • That means also undoing existing kernel changes for their devices and retooling it to support HWC & HAL v3. Lots of engineering time.
  • This solution still isnt perfect. There's a notable limitation in something called the "panel's Tearing Effect", but im not an expert at displays so CTRL+F it for the paragraph in question.
[–] Quackdoc@lemmy.world 8 points 3 days ago

This is not traditional VRR how we think of it. VRR how we think of it is changing the "frame rate" of the monitor to better suit the frame pacing of the received frames, this is not whats happening here. This is how things like freesync works. It takes your device framerate, say 60fps, and slows it down to better match the frame pacing of the content, say 48fps. Now the monitor doesn't physically change states or anything, it just allows flexible updating to match the frame pacing.

You don;t get this with this adaptive refresh rate method

Here you are effectively getting a noop every refresh cycle it doesn't need. It's still good, but not as good as what most people think of as VRR (Freesync/vesa adaptivesync, gsync etc.). You are limited to the steps your display can output. For this to be useful you require a high refreshrate display like 120hz because each application needs to align with a frame refresh.

IE. say you have a 24fps video, the display won't change it's frame pacing, but rather you get a noop every 4 frames and a refresh, (24 * 5). Now assume you have a 90hz display, 24fps has no solid divisor in 90fps, so you have to either wait for sync, or get tearing. The first one leads to judder (which can probably be mitigated using offset sync waits?) the second one is well, tearing.