-
Notifications
You must be signed in to change notification settings - Fork 284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose bindings to access the ResourceManager cache #910
Comments
Why not make it part of the API signature then? E.g. |
Same reason as to why |
So the implementation of |
What do you mean by that? Those two are distinct objects. Eg. for a custom Win2D effect:
Eg. in ComputeSharp terms, the |
This was implemented internally, will be included in the next preview releases. Closing this 🙂 |
With the work done in the two previous issues, Win2D now exposes a set of APIs to allow developers to implement custom effects. This works very well, and it's already being leveraged by ComputeSharp, which is used in the Microsoft Store to power several custom graphics components in its UI. While the new APIs cover most scenarios, there is one that is unfortunately not supported just yet, and that is retrieving WinRT wrappers for D2D images. While this is a more niche scenario, it would be nice for custom effects to benefit ffrom the same level of support of built-in Win2D effects (this has been the goal for all other features as well).
Consider this example:
Win2D will see that the effect is realized, so it will use the native D2D effect as source of truth. It will call
ID2D1Effect::GetInput
, and then invoke the resource manage to get a WinRT wrapper. Since the GUID of this D2D image is not one that's recognized by Win2D (it's just some custom effect), it will then fail to resolve a wrapper, and throw an exception:API proposal
To solve this, we should add two new APIs to allow custom effects to interact with Win2D's
ResourceManager
. Since that type is already accessible to resolve WinRT wrappers through theGetOrCreate
API, we could add the two new APIs on that same activation factory. This would also make sense given these operations are related to WinRT wrappers in general, not just COM interop.And accompanying C++/CX helpers (just like for
GetOrCreate
):Custom effects would use these two APIs in the same way as Win2D already uses the
ResourceManager
class. That is, every time they realize an effect they'd callAdd
, and every time they unrealize an effect they'd callRemove
. This would ensure that each D2D effect would be registered in the cache, so that Win2D would be able to resolve WinRT wrappers even when the effects are directly set via the D2D layer and without touching any WinRT wrappers. This would make the scenario mentioned above work correctly.While not part of the API signature, callers of
Add
are required to also have the passedIInspectable
object (ie. the custom effect) to implementIWeakReferenceSource
as well. This matches what Win2D already does, and prevents memory leaks due to a reference cycle between the underlying D2D resource and its wrapping WinRT object.The text was updated successfully, but these errors were encountered: