You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I started attaching recently released PresentMon 2.3.0 service to my project and noticed that it seems to return completely broken data in pmConsumeFrames() for client application using PresentMonAPI2.dll v2.2.0. Is doesn't look like intended service's behavior for me. The service should either provide backward compatibility for older versions of client's API libraries or return error inside pmOpenSession() to prevent such clients from reading invalid data.
The text was updated successfully, but these errors were encountered:
AlexUnwinder
changed the title
PresentMon service and client PresentMonAPI2.dll backward/forwar compatibility
PresentMon service and client PresentMonAPI2.dll backward/forward compatibility
Dec 22, 2024
Hi Alex, sorry for the delay in getting back to you. You are absolutely correct about the protocol binary compatibility between the middleware and the service.
The intention is and has always been to guarantee backward compatibility between the service and older middleware versions. We began this work by implementing the V2 dynamic query API and the introspection system, building those new systems on top of the existing shared memory module (named the Streamer).
The second part of this transition is to replace the Streamer with a more flexible shared memory buffer built on boost.interprocess, using named objects instead of fixed byte offsets to reduce brittleness by giving us added flexibility to position objects within the shared memory segment, using dynamic strides for elements within buffer objects to allow element data structures to grow without breaking compatibility, and much more.
Unfortunately, this second part was deferred in order to address more pressing issues, and so we do not as of yet have the strong backward compatibility guarantee that we intended. My apologies for not communicating this state more clearly in the documentation. I will bring up your issue in our next meeting and discuss finally prioritizing completion of this transition.
Incidentally, if you have any ideas or feedback about the IPC subsystem for transferring data, including versioning of the binary protocol, the introspection, the dynamic query API, etc., please don't hesitate to share them. Once we finalize the IPC system, this will be our final opportunity to introduce large breaking changes into the API and the binary interface.
I started attaching recently released PresentMon 2.3.0 service to my project and noticed that it seems to return completely broken data in pmConsumeFrames() for client application using PresentMonAPI2.dll v2.2.0. Is doesn't look like intended service's behavior for me. The service should either provide backward compatibility for older versions of client's API libraries or return error inside pmOpenSession() to prevent such clients from reading invalid data.
The text was updated successfully, but these errors were encountered: