search

sharpdx / SharpDX

SharpDX GitHub Repository
http://sharpdx.org
MIT License
1.69k stars 641 forks source link

Added initial support for the DXGI debug layer, might need to revise … #972

Closed ziriax closed 6 years ago

ziriax commented 6 years ago

I noticed I didn't get memory leak information about DXGI objects when calling ReportLiveDeviceObjects. I added support for the DXGI debug layer for doing this.

It also seems that using the DXGI approach to report the live objects doesn't require a device at all, so only the real leaking objects are printed, not the device/context etc that you still needed for calling ReportLiveDeviceObjects in the existing approach.

Since I had no idea how to do this correctly, I suspect feedback since this is just the first draft that is functional, but might not meet your requirements.

Thanks, Peter Verswyvelen

xoofx commented 6 years ago

Thanks, good first short! 😉

ziriax commented 6 years ago

Many thanks for SharpDX! It is such a tremendous achievement, I have used it for multiple projects currently in production.

mellinoe commented 6 years ago

I know this was already merged, but it's a bit unfortunate that the name "Debug" was used. Obviously it's a fine name and matches what it's doing, but it clashes with System.Diagnostics.Debug, which is a really commonly-used type and can force a lot of downstream code to change which references the DXGI assembly.

Not sure how it could be better, though. Maybe DxgiDebug, DxgiDebug1, etc.?

ziriax commented 6 years ago

Yes, this is annoying, but happens a lot with SharpDX anyway.

It's a bit against the convention of SharpDX to prefix classes with their DirectX library names. For example, we have SharpDX.DXGI.Factory and not DxgiFactory, and that name clashes too with all other factories in SharpDX. Same goes for Format and many more.

mellinoe commented 6 years ago

Yes, it's true that SharpDX often conflicts with itself as you've mentioned. This is a conflict with a really common system library, though, so the effect will probably be a bit larger. I'd just like to avoid having to adjust a bunch of unrelated code so that it continues to compile as it did before. Changing the name would break the naming pattern used, so I understand if it stays as-is. Just thought I'd bring it up -- I think other folks will also have to adjust their code when they upgrade and it will be a small annoyance.

xoofx commented 6 years ago

No problem renaming it to DxgiDebug/DxgiDebug1, Debug is quite annoying indeed, PR welcome

ziriax commented 6 years ago

Yes, indeed, in this case, it can break a lot of existing code, I didn't noticed that myself, since I always use namespace aliases for SharpDX.