This usually doesn't go through the normal presentation paths.
From: Zebediah Figura zfigura@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
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.
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.
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.
This merge request was approved by Jan Sikorski.