mpv-player / mpv-player/mpv

No HiDPI render (layer scaling) and automatic resolution switcher

Open
#3,271 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

meta:feature-request os:mac
Dominant language
C
Stars
37k
Forks
3.5k
Avg merge
1d 10h
Merged PRs (30d)
22

Description

Hello everyone,
I'm using the latest master of mpv on the latest release of El Capitan on a 2015 retina MBP: being the default resolution of 1440x900 a little too small for my taste, I've switched the apparent resolution to the middle "scaled - more space" one (1680x1050) via System Preference.

I was of course expecting it to have an impact on resources, but it was way more than I thought using mpv: e.g., a 60fps clip is smooth with the iGPU with the default resolution, but it drops a lot of frame with the other slightly bigger one.

I tried to play some video to investigate a bit, and the logs's show how in some of the cases the output image is even bigger than the actual max resolution of the screen, 2880 x 1800, and in the last one considerably so. Again, even if this is not entirely surprising given the retina doubling, talking with @haasn he said it should be treated as a bug, if I understood his words correctly.

Windowed 720p source:

[vo/opengl-hq] Resize: 2560x1440
[vo/opengl-hq] Window size: 2560x1440
[vo/opengl-hq] Video source: 1280x720 (1:1)
[vo/opengl-hq] Video display: (0, 0) 1280x720 -> (0, 0) 2560x1440

Fullscreen 720p source:

[vo/opengl-hq] Resize: 3360x2100
[vo/opengl-hq] Window size: 3360x2100
[vo/opengl-hq] Video source: 1280x720 (1:1)
[vo/opengl-hq] Video display: (0, 0) 1280x720 -> (0, 105) 3360x1890

Windowed 1080p source:

[vo/opengl-hq] Resize: 3840x2160
[vo/opengl-hq] Window size: 3840x2160
[vo/opengl-hq] Video source: 1920x1080 (1:1)
[vo/opengl-hq] Video display: (0, 0) 1920x1080 -> (0, 0) 3840x2160

Nonetheless, overall this has a huge impact on resources and theoretically on video quality (albeit I somewhat doubt that's actually noticeable, in fact the OS is resizing the image independently from the mpv's scalers).
Moreover, subsequently, the screenshot window command outputs a resized image instead of one with the actual resolution of the source.

Before reporting this issue I researched on my own and I saw that this was discussed a couple other times on the bug tracker or in IRC, and I understand that the current mpv's behaviour is perfectly consistent with Apple's guidelines (VLC does the same, AFAIK). Yet, for a video player like mpv, which options could already be taxing on the GPU, and well liked for its high quality output, this could lead to inconvenient outcomes.

In conclusion, if there is actually a way, it would be very good if mpv could draw its window independently from the OS' retina scaling.

If you need further logs, information or testing, I'll try to provide them all quickly.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the Retina behavior using the reported windowed and fullscreen cases, then start at the vo/opengl-hq resize and window-size handling shown in the logs. Also inspect the screenshot window command path. Done means avoiding unnecessary HiDPI layer scaling while preserving correct display behavior and source-resolution screenshots.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
desktop, performance
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.