Enabling Tracy profiling when Tracy is already used about rmlui

[p2004a]

(ops, sorry for a bit of spam caused by tagging this issue in commit I amended a bunch of times)

but I can see how it could be useful from client projects too. I'll take a look at it.

Thank you! We are very early in integration, and I don't know how zones-heavy is the library code but overall I hoped that having it on both places (and we also have enabled tracy lua integration so people can easily add zones from scripting side) can help paint a very detailed picture on where perf goes and get a better feeling about cost of certain things.

What do you think about the overloaded global new/delete operators, I guess this isn't a great idea to have enabled with external projects, or what are your thoughts?

I think I would leave it to the projects, we currently already do exactly the same thing in engine but also it's controlled by build option because it can get pretty heavy to profile all memory allocations in our case, and it's disabled in our default profiling enabled builds.

Thanks for linking that PR!

[mikke89]

Hey, always happy to hear about new integrations, and looks like a very cool project.

Yeah, we can definitely improve how we include Tracy. I mostly thought of the integration as an internal profiling tool, but I can see how it could be useful from client projects too. I'll take a look at it.

What do you think about the overloaded global new/delete operators, I guess this isn't a great idea to have enabled with external projects, or what are your thoughts?

For reference, its integration has also been discussed as part of: #446 (comment).

[mikke89]

Just made a new pull request #518 attempting to resolve this one, could you test and review? :)