compositor clock api question

Question

compositor clock api question

Geoff Hale 0

Waiting on the compositor clock is done by a call to DCompositionWaitForCompositorClock(), which looks like it is probably a wrapper around something like WaitForMultipleObjects() and some compositor event object(s). Wouldn't it have been better to expose the actual event object though, like what was done with GetFrameLatencyWaitableObject()? This would have been a lot more flexible to work with. The reason I ask is because I need to use the MsgWaitForMultipleObjectsEx() function instead.

Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-02-21T02:18:25.4+00:00

The compositor clock API offers statistics and frame rate control for presenting on-screen content smoothly, at the fastest possible cadence, and on a variety of hardware configurations.

The purpose of this signal is to replace usage of the IDXGIOutput::WaitForVBlank method, while providing higher flexibility in different refresh rates, and simplifying usage patterns for developers.

For more detais, I suggest you could refer to the Doc: Compositor clock
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-03-01T07:56:20.38+00:00

Have you got any updates about this issue?
Geoff Hale 0 Reputation points

2024-03-07T19:46:09.1833333+00:00
Nope. Still waiting for an answer, hopefully from someone involved in making the API.

I am already familiar with the documentation for the Compositor clock API.

Before the compositor clock, the main ways of waiting to draw the next frame were either:

IDXGIOutput::WaitForVBlank(), which would simply block the thread until it is time to draw the next frame.

IDXGISwapChain2::GetFrameLatencyWaitableObject(), which would give you an event object to wait on, which you would manually use via any of the relevant Wait functions. These were particularly useful as you could wait for multiple different things, all from a single thread.

The function provided by the Compositor clock API is DCompositionWaitForCompositorClock(), which seems to be a bit of a mix of these two. It can be easily used like a simple blocking function call (similar to IDXGIOutput::WaitForVBlank()) simply by not including any additional synchronization objects in the parameters. Or, if you do include some synchronization objects, you would get similar functionality to using the wait function WaitForMultipleObjects() (NOTE: I am assuming this is what happens; the documentation doesn't actually say this). However, you no longer have the flexibility offered by any of the other wait functions, which can wait on things other than synchronization objects (in my case, I wanted to wait on window messages as well as synchronization objects, using MsgWaitForMultipleObjectsEx()).

So, the Compositor clock's DCompositionWaitForCompositorClock() can fully replace IDXGIOutput::WaitForVBlank(), though can only partially replace IDXGISwapChain2::GetFrameLatencyWaitableObject(). This may be a barrier to adoption of the API.

Your answer

Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-02-21T02:18:25.4+00:00

The compositor clock API offers statistics and frame rate control for presenting on-screen content smoothly, at the fastest possible cadence, and on a variety of hardware configurations.

The purpose of this signal is to replace usage of the IDXGIOutput::WaitForVBlank method, while providing higher flexibility in different refresh rates, and simplifying usage patterns for developers.

For more detais, I suggest you could refer to the Doc: Compositor clock
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-03-01T07:56:20.38+00:00

Have you got any updates about this issue?
Geoff Hale 0 Reputation points

2024-03-07T19:46:09.1833333+00:00

Nope. Still waiting for an answer, hopefully from someone involved in making the API.

I am already familiar with the documentation for the Compositor clock API.

Before the compositor clock, the main ways of waiting to draw the next frame were either:

IDXGIOutput::WaitForVBlank(), which would simply block the thread until it is time to draw the next frame.

IDXGISwapChain2::GetFrameLatencyWaitableObject(), which would give you an event object to wait on, which you would manually use via any of the relevant Wait functions. These were particularly useful as you could wait for multiple different things, all from a single thread.

The function provided by the Compositor clock API is DCompositionWaitForCompositorClock(), which seems to be a bit of a mix of these two. It can be easily used like a simple blocking function call (similar to IDXGIOutput::WaitForVBlank()) simply by not including any additional synchronization objects in the parameters. Or, if you do include some synchronization objects, you would get similar functionality to using the wait function WaitForMultipleObjects() (NOTE: I am assuming this is what happens; the documentation doesn't actually say this). However, you no longer have the flexibility offered by any of the other wait functions, which can wait on things other than synchronization objects (in my case, I wanted to wait on window messages as well as synchronization objects, using MsgWaitForMultipleObjectsEx()).

So, the Compositor clock's DCompositionWaitForCompositorClock() can fully replace IDXGIOutput::WaitForVBlank(), though can only partially replace IDXGISwapChain2::GetFrameLatencyWaitableObject(). This may be a barrier to adoption of the API.

Share via

compositor clock api question

Your answer