Mon, 03/26/2007 - 18:59
Forums:
I have MDI application where i need to open multiple views to show different
shapes. When i toggle between different views of my application GDI object count keeps on incresing. Also, when i close one view GDI count should decrese by the amount it had increased before opening the view, but it doesn't decrese. That means GDI objects are not being released properly.
Ashish
Tue, 03/27/2007 - 10:27
Same problem persist in OCC 6.2.... When I use OCC5.2 everything works fine. Since i wanted to use textured shape functionality of 6.1, i switched to 6.1 and found GDI object leaks(can be seen in task manager).
To get this problem one can open any sample(i used topologyprimitives) and create new frame using main frame menu(Window >> New Window). Then after creating some shapes(say box in topologyprimitives sample), toggle between two views. You can find that on every redraw call new GDi objects are created and old ones are left without being released.
Can anybody suggest me the way to solve this problem? It leads to seroud refresh problem in my application.
TIA
Ashish
Wed, 04/11/2007 - 13:17
Hi,
I also have troubles with OCC 6.1 and 6.2 visualisation layer while everything is fine with OCC 5.2. I wrote a topic about that "http://www.opencascade.org/org/forum/thread_10458/".
So, Have you found something to solve this?
And could you explain how you can see the GDI leaks in the task manager ?
Thanks by advance.
Regards.
Thierry
Wed, 04/11/2007 - 17:02
Thierry
After a couple of hours debugging I found the fault you described. There are handles for a DC, bitmap and a font that aren't being relesed. Then I rembered the fix already given by Jan Brüninghaus on
http://www.opencascade.org/org/forum/thread_11016/
This releases the resources correctly, but also implements an optimised memory manager for caching already loaded fonts. I remember adding this to my 6.1 install, but haven't done it to 6.2.
If the Forum admins are monitoring this thread they should note that is SERIOUS memory leak, taking up at least 3 GDI hanles per window per font for each repaint!
Pete
Wed, 04/11/2007 - 19:46
Yes, the problem i described in this thread exists in OCC 6.2, too. I haven't found the time so far, to patch my version again and update the thread.
Interesting is, that this only occuring on windows and not on linux. I have analyzed both with a profiler and only on windows there are so many calls to load a font. The real fault must be somewhere before.
Without caching already loaded fonts the function is very _slow_, which leads to a great performance decrease while visualisating and simulation.
Wed, 04/11/2007 - 21:33
Jan,
I'm not a Linux expert, but this code is deep in the Windows specific code to handle fonts using wgl functions and so on. But I do remember read the Petzold book way back in the days of Windows 3.1 and it was always emphasised to release GDI resources after you're done with them to avoid such leaks - it was even more important back then when you only had a limited of handles for then entire operating system. When MFC evolved, most of the the handles were released in the class destructors for CDC, CFont etc so people got lazy about explicit DeleteDC/DeleteObject calls. And this is one area where my move to Qt4 still requires old GDI skills.
Anyway I'll be rolling your patch into my 6.2 version tonight.
Pete
Tue, 04/24/2007 - 10:06
Hello Pete,
Thank you for noticing and reporting this problem. It is now registered as a bug OCC15715 "[OCC Forum] Bug in OpenGl_tXfm.c, function: loadTexFont". As soon as we have the possibility we shall try to fix the problem and provide the fix in one of the next releases of Open CASCADE Technology - for the list of fixes please check the Release Notes at http://www.opencascade.org/getocc/whatsnew/.
Best regards,
Forum Supervisor
Tue, 09/30/2008 - 05:55
Unfortunately, this *critical* fix never found its way into 6.3 - even though the solution has been repeatedly provided.
Pete