vo_opengl: refactor performance data properties

Instead of having 9 different properties, requiring 18 different
VOCTRLs to read them all, they are now exposed as a single property.
This is not only cleaner (since they're all together) but also allows
querying all 9 of them with only a single VOCTRL (by using
mp.get_property_native).

(The extra factor of 2 was due to an extra query being needed to get the
type, which is now also unnecessary)

This makes it much easier to access performance metrics from within a
lua script, and also makes it easier to just show a readable, formatted
version via show-text.

1 files changed, 38 insertions, 24 deletions

diff --git a/DOCS/man/input.rst b/DOCS/man/input.rst
index 89bb41c046..d58f2dc4d5 100644
--- a/DOCS/man/input.rst
+++ b/DOCS/man/input.rst
@@ -894,30 +894,6 @@ Property list
     .. note:: This is only an estimate. (It's computed from two unreliable
               quantities: fps and possibly rounded timestamps.)
 
-``render-time-last``
-    Time needed to render the last frame in microseconds. Not implemented by
-    all VOs.
-
-``render-time-avg``
-    Average of ``render-time-last`` over the last few frames. (The exact
-    averaging time is variable, but it should generally be a few seconds)
-
-``render-time-peak``
-    Peak (maximum) of ``render-time-last`` over the last few frames.
-
-``present-time-last``, ``present-time-avg``, ``present-time-peak``
-    Analogous to ``render-time-last`` etc. but measures the time needed to
-    draw a rendered frame to the screen. Not implemented by all VOs.
-
-    (This is separate from ``render-time-last`` because VOs may interpolate,
-    deinterlace or otherwise mix multiple source frames into a single output
-    frame)
-
-``upload-time-last``, ``upload-time-avg``, ``upload-time-peak``
-    Analogous to ``render-time-last`` etc. but measures the time needed to
-    upload a frame from system memory to a GPU texture. Not implemented by all
-    VOs.
-
 ``path``
     Full path of the currently played file. Usually this is exactly the same
     string you pass on the mpv command line or the ``loadfile`` command, even
@@ -1961,6 +1937,44 @@ Property list
     whether the video window is visible. If the ``--force-window`` option is
     used, this is usually always returns ``yes``.
 
+``vo-performance``
+    Some video output performance metrics. Not implemented by all VOs. This has
+    a number of sup-properties, of the form ``vo-performance/<metric>-<value>``,
+    all of them in milliseconds.
+
+    ``<metric>`` refers to one of:
+
+    ``upload``
+        Time needed to make the frame available to the GPU (if necessary).
+    ``render``
+        Time needed to perform all necessary video postprocessing and rendering
+        passes (if necessary).
+    ``present``
+        Time needed to present a rendered frame on-screen.
+
+    When a step is unnecessary or skipped, it will have the value 0.
+
+    ``<value>`` refers to one of:
+
+    ``last``
+        Last measured value.
+    ``avg``
+        Average over a fixed number of past samples. (The exact timeframe
+        varies, but it should generally be a handful of seconds)
+    ``peak``
+        The peak (highest value) within this averaging range.
+
+    When querying the property with the client API using ``MPV_FORMAT_NODE``,
+    or with Lua ``mp.get_property_native``, this will return a mpv_node with
+    the following contents:
+
+    ::
+
+        MPV_FORMAT_NODE_MAP
+            "<metric>-<value>"  MPV_FORMAT_INT64
+
+    (One entry for each ``<metric>`` and ``<value>`` combination)
+
 ``video-bitrate``, ``audio-bitrate``, ``sub-bitrate``
     Bitrate values calculated on the packet level. This works by dividing the
     bit size of all packets between two keyframes by their presentation