GDi Objects Increasing using TBCButton ?

[Josh]

Hi
I have LAZ 1.3 fpc 2.71 installed latest BGRABITMAP 8 and BGRAControls 3.5

If I create a new project, and then add top this say 10 TBC buttons.
Using Task Manager to display the GDI  Objects
If I run this application. TaskManager will say something like 50 Objects
If I now hover over a TBC Button, the GDI Objects will increase, but not decrease when moved out of the COntrol.
After moving the mouse over the 10 buttons the GDI Objects will have increased by 20
If I click each button, Objects have increased by 40

And are not released.

Any ideas how to correct this GDI Object  'Leak' ?

[taazz]

Hi
I have LAZ 1.3 fpc 2.71 installed latest BGRABITMAP 8 and BGRAControls 3.5

If I create a new project, and then add top this say 10 TBC buttons.
Using Task Manager to display the GDI  Objects
If I run this application. TaskManager will say something like 50 Objects
If I now hover over a TBC Button, the GDI Objects will increase, but not decrease when moved out of the COntrol.
After moving the mouse over the 10 buttons the GDI Objects will have increased by 20
If I click each button, Objects have increased by 40

And are not released.

Any ideas how to correct this GDI Object  'Leak' ?

Do they keep increasing? Or after once increased they stay at the maximum number reached? to put it differently are you sure is a gdi leak and lazy loading?

[Josh]

Hi

I dont think it's a leak per se; hence the 'Leak'?

Other controls may increase when in the control,but when exiting control the extra gdi handles are freed, this does not appear to be the beahviour of tbcbutton.

If you have 'hyperthetically' 2000 tbc buttons in an application, and mouse over each; then you now have 6000 gdi objects, if you were to click these 2000 buttons you then exceed the 10000(default gdi handles) and Application crash.

[Josh]

Hi
Just curious whether anyone has confirmed this?

[circular]

This may be that the drawing of each button state is kept in memory to avoid redrawing it. If you completely free the TBCButton object, does it release the handles?

[Josh]

Hi Circular,

I have attached a small test application (quick and dirty, no real testing) , that creates 250buttons and removes them, if you launch taskmanager and watch the gdi objects.

1) on launch 22 objects,
2) click to create and now  1030
3) if you move the mouse over all controls now 1278
4) if you click some of the buttons you will see the count go up even further, I have not click them all but it will exceed 1500
5) Now if you click button to delete buttons, you will find that the count will go down to 30-32 Not back to 22

Hopefully you can see the Issue.

[circular]

I tried your test application. Well there is no leak.

When the app starts, and the library BGRABitmap is not used, 24 handles are used.

Then when the buttons are created, 10 handles are used by the library BGRABitmap, so 34 handles are used.

And for each button 4 handles are used by default, and more if more states are stored in memory.

Maybe what you could do is to query to have a property in BCButtons to free button states that are not in use. For example, the hover image and pressed image could be discarded when the normal image is displayed.

[Josh]

Hi Circular,

Thanks for your reply.

So I assume then that each button is going to take a minimum of 4 handles, I could modify to remove the handles that are created on the fly.

But having each button use 4 handles, is going to restrict its use in my situation.

So it looks like I will have to find another Button component that does not have this impact on the GDI objects.

Thank you for looking into it for me .

Do you know of another button component that has normal/hover and clicked properties; that does not have this DGI overhead?

[circular]

Here I added a property to BCButton to limit its memory usage. You can choose low, medium or high. Low is the slowest. So it also depends what speed you need.
http://forum.lazarus.freepascal.org/index.php/topic,24176.msg173350.html#msg173350

[Josh]

Hi CIrcular,

It must be me, but when I try to download a snapshot of the SVN bgracontrols-64, when I try to compile the package I am getting

C:\laz_components\bgra-controls-code-64\bgrapascalscript.pas(342,61) Hint: Local variable "Offset" does not seem to be initialized
C:\laz_components\bgra-controls-code-64\bgrapascalscript.pas(371,25) Error: Wrong number of parameters specified for call to "FilterRotate"
bgradefaultbitmap.pas(4203,29) Error: Found declaration: FilterRotate(TPointF;Single):TBGRACustomBitmap;
C:\laz_components\bgra-controls-code-64\bgrapascalscript.pas(410) Fatal: There were 2 errors compiling module, stopping

Hopefully something obvious,

Thanks for your rapid help and assistance.
Josh

Apologies forgot to check, my test machine did not have BGRABITMAP 8 installed, I have rectified this and the installation has completed, now to testing.
Again many thanks
Apologies, forgot to check my test machine did not have bgrabitmap 8, installed. Rectified

[Josh]

Hi Circular,

Just testing with the application that was creeping towards 9000 objects, after setting the Button value to Low, my GDI Objects have come down to around 1700, with very little change to performance. Wonderful.

What an amazing addition, AWESOME, BRILLIANT, SUPERB.

Thanks for this addition to a Great Package!

Josh

[circular]

You're welcome 

[Josh]

Hi Circular,

Would it be possible to implement similar MemoryUsage property in other components of the bgracontrols package.
I think the tbclabel uses 2 handles by default, I cannot remember when I was checking what the other components were using.

Such a marvelous addition.

Cheers
Josh.

[lainz]

I don't know if these set was thought in meaning of speed. Just to look awesome... But is slower that using directly the native controls or canvas (at least as far as I tested all things under Windows). Of course the result is in the look.