[lazarus] lazarus very gdi-resource hungry on windows 98

[Vincent Snijders]

On Sun, 30 Nov 2003 23:20:10 +0100
Marc Weustink <marc at dommelstein.net> wrote:

> At 22:43 30-11-2003, Vincent Snijders wrote:
> >Hi,
> >
> >Lazarus is uses very much gdi-resource (mostly pens) when I run it on
> >windows 98. I didn't test it on other win32 OSes.
> >
> >To see, what I mean open de resource meter, which shows system, user
> >and GDI resources. If I open lazarus and move another window over the
> >editor it get very soon low on GDI-resources.
> >
> >Can somebody else confirm this behaviour?
> >
> >The moving of the other windows causes a lot of repaints of the
> >editor window. Some diagnostic tool showed pens are allocated, but
> >not freed to the OS. I have been trying to find out, why they are not
> >returned to the OS, but I couldn't find anything conclusive. I
> >suspect it is because DeleteObject is called, while the pen handle is
> >still selected (in use) on the canvas. MSDN says you must not call
> >DeleteObject on gdi-objects still selected in a device context. It
> >also says it returns 0, when the call fails, but I haven't seen it
> >failing.
> >
> >I couldn't find any code in canvas.inc or pen.inc, which deselects
> >the pen, before calling DeleteObject on the pen handle.
> >
> >I am on the right track or on a wild goose chase?
> 
> the Winapi help indeed states that a object has to be deselected
> first. I don't know if it results in a leak if you don't. (In any code
> I've written so far I deselect first :)
> 
> Maybe you can just write a little test app where objects in a loop are
> 
> created, selected and the deleted.

Attached is the source code of two test programs to show the problem.
The first is gdileak.exe shows that deleting a gdi-object before
deselecting creates a gdi leak. It contains a boolean const DoItRight.
Set this to true to prevent this gdileak.

The second program lclgdileak uses the lcl to create such a program. It
has the same problems. 

I have no idea how to solve it. Maybe these programs can help testing.

Regards,
Vincent.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gz00049.gz
Type: application/octet-stream
Size: 3658 bytes
Desc: "gdileak.gz"
Url : http://localhost/pipermail/lazarus/attachments/20031201/a3935c2a/gz00049.obj