I'm a bit sad PresentData will inherit the dependencies of CommonUtilities, which complicates 3rd parties depending on just PresentData. Is there any way to avoid that?

@xnaught Thanks for reaching out. We have duplicated functionality that is spread out across multiple projects. Gradually we are refactoring to consolidate these redundancies. It seems to us that most consumers of PresentMon are invoking the console application is a child process / or as part of a batch rather than linking directly. Could you perhaps share some details on your use case? We'd like to try and make accommodations where we can here.

Hi @planetchili, thanks for the response! I'm working on a (yet unreleased) data collection application that depends on PresentData. I chose this route vs. PresentMon command line or the service so as to minimize external requirements. This change isn't the end of the world for me :) but it is nice that PresentData so easily enabled the pure embedded use case. And I realize that isn't going away with this change.

Perhaps one change that could be made is to PresentMon, to enable it to be used as a library? For instance, having the ability to specify a callback function that could be invoked in OutputThread.cpp instead of writing to CSV. That would eliminate the need to fork PresentMon as a process, and gain reuse of all the existing capture and aggregation logic already in PresentMon.

Anyway, thanks for the great library!