Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: GDI leaks using Delphi Ribbon components


This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 1 - Last Post: Sep 28, 2015 10:49 AM Last Post By: Patrick Charles
Patrick Charles

Posts: 13
Registered: 7/13/99
GDI leaks using Delphi Ribbon components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 11, 2015 10:08 AM
The Ribbon components leak GDIs. This is bad enough (performance gets slower and slower) that the users have to shut down the application a few times a day.
When the application is restarted, the performance is fine but decreases slowly and consistently.
This can be reproduced in Delphi2007, XE2 and XE6

Smallest steps to reproduce: Create a Delphi application with 1 form and drop a TRibbon on it.
Start the application and monitor the GDIs with the Task Manager. Minimize and maximize the application, you will see the number increasing.
If you use the AQTime resource profiler, the application leaks DCs and Regions.
This can be reproduced in Delphi2007, XE2 and XE6, maybe others.

Did anybody else notice that? Is there a way around or a fix?

Thank you.

Patrick

Patrick Charles

Posts: 13
Registered: 7/13/99
Re: GDI leaks using Delphi Ribbon components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 28, 2015 10:49 AM   in response to: Patrick Charles in response to: Patrick Charles
Hi all,

After some investigation, we were able to pinpoint 2 issues in the vcl.Ribbon unit. There could be more, but these 2 should be enough for now.

The first issue is in the TCustomRibbon.DrawCustomFrame procedure. There is a call to GetDCEx with no corresponding call to ReleaseDC. For our tests, we added the following line as the first line of the finally clause:
finally
ReleaseDC(FParentForm.Handle, LDC);


The second issue is in the TRibbonGroupCollapsedControl Click and CloseUp procedures.
A new TRibbonGroupDockForm gets created each time a user clicks on the control and never gets destroyed. The fix we did was to test if FFloating is assigned and reuse it if it exists instead of creating a new one. The first created TRibbonGroupDockForm is never destroyed, so we still leak one, but this should be enough for now.

If anybody is interested, I can post the code.

For our tests, we created a small application without using the vclribbon package, so compiling the code in the app.

We are lucky enough that we use packages when building our applications and that we included vclribbon in the application deployed in production. Theoretically, if we regenerated this package with the fixed unit and deployed it, this would fix our issue right?
The question is now, can we regenerate vclribbon and if yes, how can we do it? How can we tell what it contains? We used to be able to see what a package contained with the earlier version of Delphi, but we didn’t figure out how to do it in xe2.

Thanks for your help.

Patrick

Patrick Charles wrote:
The Ribbon components leak GDIs. This is bad enough (performance gets slower and slower) that the users have to shut down the application a few times a day.
When the application is restarted, the performance is fine but decreases slowly and consistently.
This can be reproduced in Delphi2007, XE2 and XE6

Smallest steps to reproduce: Create a Delphi application with 1 form and drop a TRibbon on it.
Start the application and monitor the GDIs with the Task Manager. Minimize and maximize the application, you will see the number increasing.
If you use the AQTime resource profiler, the application leaks DCs and Regions.
This can be reproduced in Delphi2007, XE2 and XE6, maybe others.

Did anybody else notice that? Is there a way around or a fix?

Thank you.

Patrick

Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02