Skip to content
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

[Clarification Needed] Why release and recreate Direct2D render target using a timer? #94

Open
codygray opened this issue Dec 20, 2022 · 0 comments

Comments

@codygray
Copy link

codygray commented Dec 20, 2022

Throughout the library, in the implementation of all controls that use Direct2D for painting, the handler for WM_PAINT messages sets a timer (with a timeout value of 30 seconds) that, when fired, calls the xd2d_free_cache helper function. This function, as the name suggests, destroys the Direct2D drawing cache by calling ID2D1RenderTarget::Release. What this means is, if more than 30 seconds elapse between paint events, the Direct2D drawing cache must be recreated again (via ID2D1Factory::CreateHwndRenderTarget, which is called by the xd2d_paint helper function).

This design must have been implemented for a reason, since the design and implementation of the library is extremely thoughtful, but I cannot figure out what that reason is. It seems like a performance pessimization. The MSDN documentation for ID2D1Factory::CreateHwndRenderTarget specifically recommends that render targets should be created once and retained as long as possible:

By creating a render target once and retaining it as long as possible, you gain performance benefits. Your application should create render targets once and hold onto them for the life of the application or until the D2DERR_RECREATE_TARGET error is received. When you receive this error, you need to recreate the render target (and any resources it created).

Is this design attempting to reduce memory overhead, even at the expense of drawing speed? Or is there some other motivation?

I'm anxious to hear your thoughts/explanation about why this decision was made. This is not (yet) a request to change the code. In fact, I'm asking because I'm currently working on a series of improvements to the Chart control, so if it turns out that this design is the pessimization that I suspect it may be, I can change it as part of my upcoming set of PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant