From: Jeremy W. <jez...@ho...> - 2011-03-21 20:38:41
|
> > What version of Perl are you using? > > Perl 8.8 and Perl 10.0 (both ActiveState's) - results the same I assume that's perl 5.8.8? It may be worth downloading the latest version of either 5.8 or 10.0 as I know there were fixes in Perl itself that could be causing your problem. > The most interesting fact in this second case is the behaviour of Prima > windows when I comment the close method out. Then I see on the screen all the > windows created one after another! And - of course - MAD effect arises. > > Mayby all the problem is that I do not use in Win32::GUI a similar method to > that ->close() ? But I can not find it though. With Win32::GUI you shouldn't need to do anything. Once the object goes out of scope, all resources should be released. > > It's likely that the issue you are having in your > > application is that you are storing references to Win32::GUI objects in > > different places so the reference count never gets to zero thus the object > > isn't destroyed. > But what about my example? > Jez, add a loop which adds to one window say 200 labels or textfields and check > what will happend. On my machine it needs 100-150 iterations to blow up. It is > not a "theoretical" example I have attached. I believe if I could fix the MAD > problem in the simple example then I could repair my application. Your example runs fine for me. With 400 labels and 4000 iterations, I leak about 128K. Handles, User Objects and GDI objects don't leak either. At the end of the run, your script uses 5MB. I am using Activestate Perl 5.8.9 build 827. > > I've found the "big memory problems" are associated with > > leaking windows handles and GDI objects (open task manager and display > > these columns, if they keep increasing then you need to work out why). > I can't fine the windows handles and GDI objects in my task manager - where are > they? Open Windows task manager, then under the view menu you should see Select columns, then select Handles, User Objects and GDI objects. If handles, user objects or GDI objects keep increasing in number then you'll end up with a serious problem - strange colors or wrong bitmaps painted can sometimes be seen. Cheers, jez. |
From: Jeremy W. <jez...@ho...> - 2011-03-24 09:36:37
|
Hi, Cool - do some major testing with your app, and if things are still OK, the fix (well, a version of it) will get committed to CVS. Interesting that you are still having memory issues with 5.12. This could be another issue within Win32::GUI that only manifests in those versions of perl... Cheers, Jez. > From: wb...@sa... > To: jez...@ho... > Subject: Re: [perl-win32-gui-users] problem of reusing memory > Date: Wed, 23 Mar 2011 22:25:24 +0100 > CC: per...@li... > > Jeremy, > > It works! > > I had to take the 5.8.9 version. Firstly I try to take perl 5.10 and 5.12 > versions but both suffer from this memory problem. > > Thank you for your great help! > > Regards > Waldemar |
From: Waldemar B. <wb...@sa...> - 2011-03-25 10:08:01
|
Hi, > Cool - do some major testing with your app, and if things are still OK, the > fix (well, a version of it) will get committed to CVS. Until now I rewrote my application to use the fix and first tests are really promising. By the way, this tremendous GDI object number was due to the fact that each label and textfield had its own font which in turn is just GDI object and the same with background. Syntax of background color in Win32::GUI is little misleading (-background => 0xffffff) as it suggests that it is simple attribute of a widget. But it is not the case: each background is full GDI object too! Maybe - I am just speculating - that was the fundamental reason why the background color error raised? Who - at first sight - could see that there is a such big difference between -background and -foreground? So these two problems seems to be overcome for me and I am much more happy! > Interesting that > you are still having memory issues with 5.12. This could be another issue > within Win32::GUI that only manifests in those versions of perl... I have to check it once again. For a few days I've got such a big mess in my Perl environments so I could overlooked something. I hope to do it in this weekend. Cheers, Waldemar. |
From: Aldo C. <da...@pe...> - 2011-03-25 11:41:46
|
On 25.03.2011 11:07, Waldemar Biernacki wrote: > Until now I rewrote my application to use the fix and first tests are really > promising. By the way, this tremendous GDI object number was due to the fact > that each label and textfield had its own font which in turn is just GDI object > and the same with background. as I just wrote in another mail, there should be no problem with fonts, because you create them explicitly. this means the same GDI object is used for all controls. only the brush is created "on-demand" for background. > Syntax of background color in Win32::GUI is little misleading (-background => > 0xffffff) as it suggests that it is simple attribute of a widget. But it is not > the case: each background is full GDI object too! Maybe - I am just > speculating - that was the fundamental reason why the background color error > raised? Who - at first sight - could see that there is a such big difference > between -background and -foreground? the difference is in the Win32 API. they allow a plain COLORREF for foreground, but only a HBRUSH for background (even if you just want a solid color, you have to create a solid brush for this). I thought it was "user friendlier" to automatically create a brush of the given color. it's just that I forgot to clean it up afterwards :-) maybe it would be a good idea to add a -backgroundbrush option, so you can pass a Win32::GUI::Brush object to it and the same GDI object will be used for all controls, as with fonts. cheers, Aldo |
From: Waldemar B. <wb...@sa...> - 2011-03-27 21:40:46
|
Dnia piątek, 25 marca 2011 o 12:43:14 Aldo Calpini napisał(a): > On 25.03.2011 11:07, Waldemar Biernacki wrote: > > Until now I rewrote my application to use the fix and first tests are > > really promising. By the way, this tremendous GDI object number was due > > to the fact that each label and textfield had its own font which in turn > > is just GDI object and the same with background. > > as I just wrote in another mail, there should be no problem with fonts, > because you create them explicitly. this means the same GDI object is > used for all controls. only the brush is created "on-demand" for > background. Of course you are right. It is not a problem with using font in general but with my using them. > > Syntax of background color in Win32::GUI is little misleading > > (-background => 0xffffff) as it suggests that it is simple attribute of > > a widget. But it is not the case: each background is full GDI object > > too! Maybe - I am just speculating - that was the fundamental reason why > > the background color error raised? Who - at first sight - could see that > > there is a such big difference between -background and -foreground? > > the difference is in the Win32 API. they allow a plain COLORREF for > foreground, but only a HBRUSH for background (even if you just want a > solid color, you have to create a solid brush for this). I thought it > was "user friendlier" to automatically create a brush of the given > color. it's just that I forgot to clean it up afterwards :-) You right again; this syntax is really friendly but the real problem with the error was that it feeds the GDI quota limit vary fast (in my application) - not just the memory. Adding bad desing with fonts and error in Perl 5.10 you can see my problems... :( But thankfull Jeremy code I fixed the error and using Perl 5.8 version with changes in my application give the result that I have quite stable application now. I tried to do it in 5.12 but I didn't manage. At first ExtUtils::FakeConfig from cpan had no 5.12 version. I thank I corrected it but compilation Win32::GUI with gcc failed (tests showed it). Because I can't find ppm for 5.12 so I think I have made a mistake writing the information about Win32::GUI in Perl 5.12. Sorry for that. > maybe it would be a good idea to add a -backgroundbrush option, so you > can pass a Win32::GUI::Brush object to it and the same GDI object will > be used for all controls, as with fonts. This would be fine for I use them (backgrounds) synchronized in my windows so I can get the same colour to the quite big group of widgets. cheers Waldemar. |
From: Aldo C. <da...@pe...> - 2011-07-16 15:08:22
|
On 24.03.2011 10:36, Jeremy White wrote: > Hi, > > Cool - do some major testing with your app, and if things are still OK, > the fix (well, a version of it) will get committed to CVS. I committed the changes to fix the -background option GDI object leak. I also added a -backgroundbrush option, which can be used instead of -background if you are creating a huge number of windows with the same background. eg. instead of: $window->AddLabel( -background => 0xff00ff, ... ); you can do this: use Win32::GUI::Constants; my $brush = Win32::GUI::Brush->new( -style => BS_SOLID, -color => 0xff00ff, ); $window->AddLabel( -backgroundbrush => $brush, ... ); this way you can effectively use the same $brush for several windows and avoid creating too much GDI objects. (of course you have to take care that $brush remains in scope, otherwise you may get errors or funny looking windows). the changes will be available with the next release of Win32::GUI. cheers, Aldo |
From: Waldemar B. <wb...@sa...> - 2011-03-22 06:41:39
|
Uff some _real_ progress! Athough I am not full satisfied. > It may be worth downloading the latest version of either 5.8 or 10.0 as I > know there were fixes in Perl itself that could be causing your problem. 1. Yes! Installing Perl 5.8.9 helps. No memory drifting. 2. At last I have found this columns. Problem was I had a Polish version of Windows and I was unconsciensly looking for the word "columns" and not the Polish word "kolumny", which - as even no-Polish people can see - is the same word. I definitely work too much... Finding the GDI objects number was crucial. It was written 10000 and maximum - according Microsoft is 65,536 (for XP). The number is written in registry under the key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota So I have too big succeses: no MAD efect and my application can work. One of my application biggest window has over 1000 GDI objects... wow! That was the reason that I could open it only 10 times! When I'll increase the 'quota' number I'll get rigths to open my windows about 60 times. Not bad! I'am a little ironic, sorry of that! Luckily I have special way of acting my application, that the application windows are not removed but only hide and rising the 'quota' number helps a lot to remember full application in the memory. However problem of reusing undefined objects remains. Now I know that it is not problem with the memory but with deleting graphical objects. Jez I wonder what is a differences between your and my installations of Win32::GUI (and windows) that I have problem with GDI objects number (objects are not deleted) and you not? I have checked Perl 5.8.9(829) from 21-01-2011 08:00:46. I use also Prima and I do not find version for Perl 5.10 - I have for 5.12 (the newest). Is it save to install Win32::GUI from Perl 5.10 in Perl 5.12? Thank you Jez for help! Waldemar |
From: Jeremy W. <jez...@ho...> - 2011-03-22 12:30:03
|
> Finding the GDI objects number was crucial. It was written 10000 and maximum - > according Microsoft is 65,536 (for XP). The number is written in registry > under the key: > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows > NT\CurrentVersion\Windows\GDIProcessHandleQuota Vista and Windows 7 have larger default values, but you really need to work out why you are using so many GDI objects. It shouldn't be that high... > However problem of reusing undefined objects remains. Now I know that it is not > problem with the memory but with deleting graphical objects. > > Jez I wonder what is a differences between your and my installations of > Win32::GUI (and windows) that I have problem with GDI objects number (objects > are not deleted) and you not? I do a lot of GDI drawing and have no leaking GDI objects (I hope!). As long as the object (pen, font etc) goes out of scope after you've used it then the GDI handle will be freed. For example, say you do something like this (sudo code): my $pen = new Win32::GUI::Pen( -color => [ rand()*255, rand()*255, rand()*255 ], -width => rand()*5, ); %pens{$pen} = $pen; #do some drawing undef $pen; The pen is stored in a global hash, and therefore will never be deleted. I also find creating and destroying GDI objects has performance implications (Windows not perl) so I tend to store pens, brushes, fonts in objects so I can just reuse them. You should be able to reuse GDI objects across windows (as long as the window and object were created in the same thread). > I have checked Perl 5.8.9(829) from 21-01-2011 08:00:46. > I use also Prima and I do not find version for Perl 5.10 - I have for 5.12 (the > newest). Is it save to install Win32::GUI from Perl 5.10 in Perl 5.12? Personally I've always had 'issues' with Perl 5.10.x which is why I have stuck with with 5.8.x - I have been meaning to try 5.12 but have never got round to it. Cheers, jez. |
From: Waldemar B. <wb...@sa...> - 2011-03-23 12:37:03
|
Jeremy I've forgotten to send it to the list so it is the second copy... Dnia środa, 23 marca 2011 o 11:22:52 napisałeś: > > > Vista and Windows 7 have larger default values, but you really need to > > > work out why you are using so many GDI objects. It shouldn't be that > > > high... > > > > I use about 1000 them in my biggest window - it is a table 12x20 of > > textfields plus their borders (I do them independently - I wanted to > > have them in color and of various width), some buttons width pictures on > > them, that's it. All my window cascade can have about 2000-3000 GUI > > objects maximum.. > > Could you send me a screenshot of this window so I can understand? Text > fields shouldn't use any GDI handles. So you draw your own boarders? Do > you reuse objects? Probably I am mixing something. I wrote another variant of the script: test.pl: ########################################## #!/usr/bin/perl -w use strict; use warnings; use Win32::GUI qw(); my $i = 0; while ( $i < 100 ) { $i++; { my $ch = Win32::GUI::Window->new( -name => "ch1", -text => "child window", -pos => [ 100+10*$i %800, 50 ], -size => [ 300 , 250 ], -background=>0xffaaff, ); for ( my $j = 0; $j < 1000; $j++ ) { $ch->{"lab_$j"} = $ch->AddLabel( -name => 'ch1_'.$j, -text => 'ch1_'.$j, -pos => [ 10, 0 ], -size => [ 300, 50 ], -background=>0xff00ff, ); } $ch->Show(); print "$i:\t",$ch,"\n"; undef $ch; } } $i=0; Win32::GUI::Dialog(); __END__ ################################# and on the site: http://sao.pl/win32-gui/ are images of my screen. The description is here: The Perl script "test.pl" was performed on my windows XP machine (virtual one, but I have the same results on 'true' Windows 7 64 bits host machine (HP laptop machine), I put the results from vitual machine because gimp can easier catch the result - at least I can do that :) Moreover: The error_1.png shows that there are 52074 GDI objects when the iteration 52 was performed. Everything is reasnable: 52 iteration steps times 1000 labels in each iteration gives 52000. Plus start objects and so on. The error_2.png is just after catastrophy. The error_3.png shows after script has finished. The error_4.png shows that screen refreshing is gradual: task bar is partially restored. Say it something to you? > I think there was a bug fixed in Perl which is why you are finding the > problem in some versions and not in others. But this is conneced only with the memory, NOT with the number of GDI objects. Besides strange is that in versions 5.8.8 and 5.8.9 (activestate and compiled) this memory issue does not apear whereas on 5.10th version does. > GDI objects do auto delete > when they go out of scope (at least they do for me). I thought that in my demo script it should be deleted after each iteration step. Maybe my script is errored. Please correct it. It is extremally simple so everything can be done! > I can create millions > of GDI objects during the run of my application. At this stage, I think > its a bug in your code or a design issue where you keeping hold of GDI > objects. See the upper remark - what there should be corrected? > In hindsight I would have looked more closely at wxPerl (for cross platform > support) but I am happy with Win32::GUI. As it's built in C and hits the > Win32 API directly you can do things that other GUI frameworks can't. I'm > doing some interesting things with threads that you would struggle to do > even in C#. Generally threads are not connected with GUI so other GUI versions in Perl are good too. I agree that this additionally graphic libraries in Win32-GUI are big advantages of Win32-GUI. But in my case when I do program for every-day managing SQL databases by many user simultaniously, the possibility to run program on three main systems: Windows, Linux and www-Browser in identical way is quite usefull for organizations (write one time and use everywhere). My idea seems to by similar to java, but in fact it is not - My goal is to write an application using very, very high script language and without any compilation of any kind. If you add command to the script the change works at once - like writing CGI scripts, but without any risk of errors (in the database). Better is to compare my scripts to html not to cgi, but not so long in si OK stop it. > Ok, to solve this we need to find out where and why you are using so many > GDI handles? Could you send screenshots/examples of your code where you > draw to the screen? As I said, point your brawser to http://sao.pl/win32-gui/ Thank you Waldemar PS. I've read Aldo remarks very carefully. Thank you! I have found the considerations before and already tried to use it but nothing had changed. I think that it is a different issue. |
From: Jeremy W. <jez...@ho...> - 2011-03-23 12:48:28
|
> Probably I am mixing something. I wrote another variant of the script: > test.pl:> ##########################################> #!/usr/bin/perl -w> use strict;> use warnings;> use Win32::GUI qw();> my $i = 0; Ok:) as soon as I saw your code, I can see the problem...The problem is: -background=>0xff00ffComment out those lines and you'll have no memory or GDI leak...checkout this bug report on sourceforge:http://sourceforge.net/tracker/?func=detail&aid=2864551&group_id=16572&atid=116572A while back I did try and fix this bug as I had the same problem, but didn't find a quick fix (it's in XS/C not perl). If possible, could you add your example to this bug report as someone might fix it for the next release of Win32::GUI (several people have been hit by this bug, and in your case it's fatal).As a work around, I draw the text/background manually - which worked well in my case (as text fields/labels wasn't the right design approach). Not sure if that could work for you...Cheers,Jeremy. |
From: Waldemar B. <wb...@sa...> - 2011-03-23 13:34:05
|
Dnia środa, 23 marca 2011 o 13:46:46 Jeremy White napisał(a): > > Probably I am mixing something. I wrote another variant of the script: > > > test.pl:> ##########################################> #!/usr/bin/perl > > -w> use strict;> use warnings;> use Win32::GUI qw();> my $i = 0; > > Ok:) as soon as I saw your code, I can see the problem...The problem is: > -background=>0xff00ffComment out those lines and you'll have no memory or > GDI leak...checkout this bug report on > sourceforge:http://sourceforge.net/tracker/?func=detail&aid=2864551&group_ > id=16572&atid=116572A while back I did try and fix this bug as I had the > same problem, but didn't find a quick fix (it's in XS/C not perl). If > possible, could you add your example to this bug report as someone might > fix it for the next release of Win32::GUI (several people have been hit by > this bug, and in your case it's fatal).As a work around, I draw the > text/background manually - which worked well in my case (as text > fields/labels wasn't the right design approach). Not sure if that could > work for you...Cheers,Jeremy. OK. Thank you very much! Now I know more and l lost the ilusion that something can be simple. But: 1. Stil my first example couses leak of memory in Perl 5.10 - I've just did it: after few hundred iterations it has took 250MB RAM - so it is another problem. You do - from this point of view - rightly working in Perl 5.8 version. 2. The problem of the background color is a serious one and nobody seems to workout it in a reasonable time horizon. It is a very, very bad news for me because one of the main method of my application is to inform a user about meaning of different numbers with differen by colors (which in turn can be defined by people themself). He he, I even did textfield's borders in color. Without all the color staff the applications will not be so talkative as they are now. Thank you for your help and comments! I thing the thread can be close. Waldemar. |
From: Waldemar B. <wb...@sa...> - 2011-03-23 13:51:45
|
One more thing - maybe important. This background color problem is not neccesary connected with a memory. I think that maybe the bigger problem is that it rises the GDI object counter. Please compare difference between Perl8 and Perl10 - in Perl 5.8 in principle the memory is stable whereas in Perl10 it blows up. Jeremy, how you manage the beckground problem? May you scatch it? Waldemar |
From: Jeremy W. <jez...@ho...> - 2011-03-23 14:42:44
|
> One more thing - maybe important. This background color problem is not > neccesary connected with a memory. I think that maybe the bigger problem is > that it rises the GDI object counter. Please compare difference between Perl8 > and Perl10 - in Perl 5.8 in principle the memory is stable whereas in Perl10 > it blows up. The memory issue you are seeing in 5.10 is a perl bug (my understanding). When GDI handles aren't released they can use a significant amount of memory . > Jeremy, how you manage the beckground problem? May you scatch it? I'm not sure the approach I use would help you as I draw the whole screen (fonts, graphics, backgrounds etc). I've looked at this again, and I think I've fixed the bug within Win32::GUI. You mentioned that you built Win32::GUI from scratch, so if you replace the DestroyWindow method in GUI.xs (around line 2231) with the code below it should fix things for you... ########################################################################### # (@)INTERNAL:DestroyWindow()BOOLDestroyWindow(...)CODE: HWND handle; LPPERLWIN32GUI_USERDATA perlud; handle = (HWND) handle_From(NOTXSCALL ST(0)); perlud = (LPPERLWIN32GUI_USERDATA) GetWindowLong(handle, GWL_USERDATA); if(ValidUserData(perlud) ) { //free any resources...need to check other things like fonts etc if (perlud->hBackgroundBrush != NULL) { DeleteObject((HGDIOBJ) perlud->hBackgroundBrush); perlud->hBackgroundBrush = NULL; } } RETVAL = DestroyWindow(handle);OUTPUT: RETVAL |
From: Waldemar B. <wb...@sa...> - 2011-03-23 21:25:33
|
Jeremy, It works! I had to take the 5.8.9 version. Firstly I try to take perl 5.10 and 5.12 versions but both suffer from this memory problem. Thank you for your great help! Regards Waldemar |
From: Aldo C. <da...@pe...> - 2011-03-23 15:22:52
|
On 23.03.2011 15:42, Jeremy White wrote: > I'm not sure the approach I use would help you as I draw the whole > screen (fonts, graphics, backgrounds etc). I've looked at this again, > and I think I've fixed the bug within Win32::GUI. You mentioned that you > built Win32::GUI from scratch, so if you replace the DestroyWindow > method in GUI.xs (around line 2231) with the code below it should fix > things for you... I think this would be better placed in the Perlud_free() function found in GUI_Helpers.cpp. this is automatically called upon WM_QUIT message for all windows created by Win32::GUI, so you don't even need to relay on Perl calling DESTROY on objects. if you want, I can commit this to CVS as soon as I get to setup my dev. environment :-) cheers, Aldo |
From: Jeremy W. <jez...@ho...> - 2011-03-23 16:14:56
|
> On 23.03.2011 15:42, Jeremy White wrote: > > I'm not sure the approach I use would help you as I draw the whole > > screen (fonts, graphics, backgrounds etc). I've looked at this again, > > and I think I've fixed the bug within Win32::GUI. You mentioned that you > > built Win32::GUI from scratch, so if you replace the DestroyWindow > > method in GUI.xs (around line 2231) with the code below it should fix > > things for you... > > I think this would be better placed in the Perlud_free() function found > in GUI_Helpers.cpp. this is automatically called upon WM_QUIT message > for all windows created by Win32::GUI, so you don't even need to relay > on Perl calling DESTROY on objects. if you want, I can commit this to > CVS as soon as I get to setup my dev. environment :-) My code was only a hack:) Yes, perlud_free is the ideal place - go ahead an commit it to CVS:) There may be other objects that need deleting (fonts) and it looks like there is a minor leak somewhere aswell... Does this mean you are "back for good"? Cheers, Jeremy. |
From: Aldo C. <da...@pe...> - 2011-03-25 11:36:17
|
On 23.03.2011 17:12, Jeremy White wrote: > My code was only a hack:) Yes, perlud_free is the ideal place - go ahead > an commit it to CVS:) good, if I remember how to do it :-) (not using CVS anymore since years...) > There may be other objects that need deleting (fonts) and it looks like > there is a minor leak somewhere aswell... nope, with fonts you pass an already created handle, which means the GDI object is destroyed when $font (eg. the Perl object) goes out of scope. the problem occurs only with the brush, which is a GDI object created automatically when parsing windows creation options. > Does this mean you are "back for good"? I really hope so :-) I may need some time to catch up with the current shape of Win32::GUI, but I'm willing to lend a helping hand where I can. cheers, Aldo |