ICustomDrawOperation object lifetime and ICustomDrawOperation.Dispose #15206
-
In my project I am using ICustomDrawOperation extensively. I have some confusion around the lifetime of the draw operations, and so I am hoping someone could provide clarification. The trouble: ICustomDrawOperation inherits IDisposable, but I cannot figure out how to know when the draw operation is safe to dispose. The problem is that a single draw operation can have its Render function called multiple times. For example, hovering over a list box item leads to the deferred renderer calling the same ICustomDrawOperation.Render multiple times. Since the deferred renderer can reuse the same ICustomDrawOperation, how do I know when it is safe to dispose? The source examples don't provide any clarification, as they all implement Dispose as a no-op. I've tried to hook into Compositor.RequestCompositionUpdate, but this gets ugly (and is on the UI thread instead of render thread), and it doesn't seem a safe workaround. This is more of an XY problem (though I'm still curious about the above), but what I'm really trying to do is create a pool of reusable WriteableBitmap objects. I ran into a race condition between the UI and rendering threads that looks like this: UI thread: Calls DrawingContext.DrawImage for a WriteableBitmap As a workaround, I thought I could use ICustomDrawOperation to post back to the UI thread when the rendering operation was complete, and return the WriteableBitmap back to the pool there. This doesn't work, because ICustomDrawOperation.Render can be called multiple times per instance, so I have no idea when to return a bitmap to the pool. The problems are similar: is there a general way to know when the deferred renderer no longer holds a reference to an ICustomDrawOperation or a WriteableBitmap? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
cc @kekekeks |
Beta Was this translation helpful? Give feedback.
-
I think RenderDataCustomNodewas supposed to implement IDisposable and propagate Dispose call to ICustomDrawOperation in the same way as RenderDataBitmapNode does. Probably lost during migration from the old rendering code. As of WriteableBitmap There is a known problem with our WriteableBitmap implementation not doing actual data snapshots. No ETA for a fix. |
Beta Was this translation helpful? Give feedback.
-
Thank you for the answer, yes it makes sense that the draw operations were meant to be disposed by the rendering side. I tested it just now and this is sufficient to propagate the dispose to ICustomDrawOperation:
Should I submit an issue and pull request? |
Beta Was this translation helpful? Give feedback.
Thank you for the answer, yes it makes sense that the draw operations were meant to be disposed by the rendering side. I tested it just now and this is sufficient to propagate the dispose to ICustomDrawOperation:
Should I submit an issue and pull request?