[PATCH 0/1] MR903: ddraw: Add FPS tracing in ddraw_surface_update_frontbuffer().

[Zebediah Figura (＠zfigura)]

This usually doesn't go through the normal presentation paths.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/903

[PATCH 1/1] ddraw: Add FPS tracing in ddraw_surface_update_frontbuffer().

[Zebediah Figura]

From: Zebediah Figura <zfigura(a)codeweavers.com>

This usually doesn't go through the normal presentation paths.
---
 dlls/ddraw/ddraw_private.h |  3 +++
 dlls/ddraw/surface.c       | 16 ++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/dlls/ddraw/ddraw_private.h b/dlls/ddraw/ddraw_private.h
index 0c2a491d45b..159ce987dc3 100644
--- a/dlls/ddraw/ddraw_private.h
+++ b/dlls/ddraw/ddraw_private.h
@@ -136,6 +136,9 @@ struct ddraw
 
     struct wined3d_stateblock *state;
     const struct wined3d_stateblock_state *stateblock_state;
+
+    unsigned int frames;
+    DWORD prev_frame_time;
 };
 
 #define DDRAW_WINDOW_CLASS_NAME "DirectDrawDeviceWnd"
diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c
index e4382a74ecd..4a95067996f 100644
--- a/dlls/ddraw/surface.c
+++ b/dlls/ddraw/surface.c
@@ -24,6 +24,7 @@
 #include "ddraw_private.h"
 
 WINE_DEFAULT_DEBUG_CHANNEL(ddraw);
+WINE_DECLARE_DEBUG_CHANNEL(fps);
 
 static struct ddraw_surface *unsafe_impl_from_IDirectDrawSurface2(IDirectDrawSurface2 *iface);
 static struct ddraw_surface *unsafe_impl_from_IDirectDrawSurface3(IDirectDrawSurface3 *iface);
@@ -87,6 +88,21 @@ HRESULT ddraw_surface_update_frontbuffer(struct ddraw_surface *surface,
     if (w <= 0 || h <= 0)
         return DD_OK;
 
+    if (!read && TRACE_ON(fps))
+    {
+        DWORD time = GetTickCount();
+        ++ddraw->frames;
+
+        /* every 1.5 seconds */
+        if (time - ddraw->prev_frame_time > 1500)
+        {
+            TRACE_(fps)("%p @ approx %.2ffps\n",
+                    ddraw, 1000.0 * ddraw->frames / (time - ddraw->prev_frame_time));
+            ddraw->prev_frame_time = time;
+            ddraw->frames = 0;
+        }
+    }
+
     /* The interaction between ddraw and GDI drawing is not all that well
      * documented, and somewhat arcane. In ddraw exclusive mode, GDI draws
      * seemingly go to the *original* frontbuffer/primary surface, while ddraw
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/903

[Henri Verbeet (＠hverbeet)]

I'm not against this, but note that in the cases where this doesn't already go through wined3d_swapchain_present(), we're not necessarily updating a full "frame" as such. That's particularly true for applications using Blt()/BltFast() to update the front buffer.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/903#note_8959

[Zebediah Figura]

On 9/21/22 04:31, Henri Verbeet (@hverbeet) wrote:
> I'm not against this, but note that in the cases where this doesn't already go through wined3d_swapchain_present(), we're not necessarily updating a full "frame" as such. That's particularly true for applications using Blt()/BltFast() to update the front buffer.

I don't know ddraw very well; is there a better heuristic that occurs to 
you?

If it's just a matter of "some applications are going to blit multiple 
sub-rects to the front buffer", I'm inclined to commit this anyway, 
perhaps with an added code comment to that effect, on the grounds that a 
heuristic that works sometimes and fails other times is still better 
than none at all. I welcome disagreement on that though.

[Henri Verbeet (＠hverbeet)]

> I don't know ddraw very well; is there a better heuristic that occurs to you?

It's mostly just a consequence of the origins of ddraw; at least initially this was mostly just used as a replacement for the DOS model of applications writing directly to the framebuffer. Flip() exists, but isn't necessarily used a lot by early ddraw applications.
> If it's just a matter of "some applications are going to blit multiple sub-rects to the front buffer", I'm inclined to commit this anyway, perhaps with an added code comment to that effect, on the grounds that a heuristic that works sometimes and fails other times is still better than none at all. I welcome disagreement on that though.

Yeah, as I said, I'm not necessarily opposed to this patch. I'd argue for tweaking the language a bit, perhaps "frontbuffer updates per second", or simply "updates per second" instead of "fps", but perhaps that's just splitting hairs.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/903#note_9044

[PATCH 0/1] MR903: ddraw: Add FPS tracing in ddraw_surface_update_frontbuffer(). - approved

[Jan Sikorski (＠jsikorski)]

This merge request was approved by Jan Sikorski.
-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/903