Hi.
We upgraded inhouse ERP software from Delphi 7 to Delphi 2007. As the Quantum Grid 3 is no longer supported in Delphi 2007 we updated all grids in our application to Quantum Grid 6. The application is a single binary application with about 2 million lines of code (including source code of 3rd party components like the dxVCL components. The application has over 300 TcxGrid components. All forms that show grids are created on demand and are destroyed right after the form is closed. This way only a small part of the software is loaded into memory and the memory footprint is quite small.
But since the deployment of the latest release we are encountering severe GDI resource problems. Our users are working in Citrix Metaframe hosted on Windows Server 2003 and usually start two to four instances of our application. That was possible with our former version with Quantum Grid 3 but with Quantum Grid 6 the users can't launch a third instance of our application because of an Windows error message "Out of resources". Our global exception handler (ExceptionalMagic) records the call stack for these exception (s. text file in attachment) and it looks like a GDI allocation problem.
I wrote two sample applications in Delphi 7 with QGrid 3 and Delphi 2007 with QGrid 6 to prove the increased resource requirements (s. attachment). The new grid seems to reserve about 60 percent more gdi resources than QGrid 3 without any skins or any data displayed in the grid. Is there a way to reduce GDI resource requirements or increase the limits for the GDI resources in Windows?
Kind regards
Kay Zumbusch
Ticket
Q99935
Visible to All Users
Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Hi.
We are using version 33 at the moment and did not update to 34 yet but planned to update for a future release. We are patching highly critical errors in our application at the moment without any updates of component sets. Unfortunately you added more skins to version 34 and as we introduced ExpressSkins in our recent version nearly all of our users assume that the new design of our application causes the resource problems. Therefor we don't like to add even more skins to our application at the moment.
The GDI resource count of your tests seems to be accurate.
Kind regards
Kay Zumbusch
Hi Kay,
Please clarify which version of our products you're using. The latest Build available is 34, while the Version field in this report states 6.31. If you're using Build 31, we recommend that you download Build 34 and update to it. Build 34 addresses a number of critical issues in the ExpressSkins Library. If you're not going to use skins, you should unload all ExpressSkins~ packages and remove skin units from the 'uses' clause in your projects.
As for GDI resources, I ran Windows Task Manager and the attached dxGrid6 and dxGrid3 executables to see 129 and 105 GDI Objects allocated, respectively. Please compare your results.
We're looking forward to hearing from you.
Thanks,
Alex
After checking any of the above options, please let us know your results.
We still recommend Build 34 if you're going to use skins in your application. With the modular skin package architecture and dynamic skin loading introduced in this Build, you'll decrease an application's memory usage and executable size.
Thanks,
Alex
Hallo.
I just added a TdxSkinController to my dxGrid6 sample application and selected a skin. The GDI object count is now 132 compared to 131 without the skincontroller.
I might add, that we are able to launch a lot more instances of our application on a regular Windows XP or Windows Server 2003 workstation. We already checked the dektop heap buffer. On the regular workstations we get the resource problem if the upper limit of the desktop heap is reached (default 3 MB) but on the Citrix terminal server there is plenty of desktop heap memory left when the gdi limit is reached.
We are just updating the dx components to version 34. I'll recheck the GDI resources with this release and will report back.
Kind regards
Kay Zumbusch
Thank you, Kay. Keep us informed of your progress.
Thanks,
Alex
Hi.
Here is some more information about GDI usage. I modified the dxGrid6 sample project and compiled it with Delphi 2007. The skins are not dynamically loaded at the moment. I'll evaluate the dynamic loading of the skins, if we are able to use it in our application to reduce the memory footprint of the application.
My results:
dx version 33 without skins: 56 USER objects, 131 GDI objects
dx version 33 with all skins: 55 USER objects, 132 GDI objects
dx version 34 with all skins: 56 USER objects, 133 GDI objects
I used the Caramel skin in this application.
We also found out today that the resource problem occurs on a Windows Terminal Server (without Citrix), too. We will start a Microsoft support call to get some more detailed information about the resource management. I'll keep you informed.
Kind regards
Kay Zumbusch
Hi Kay,
Any results on the subject?
Thanks,
Alex
Hi.
Microsoft was able to provide a solution. User session on a terminal server are very limited in memory footprint by resticted default settings. The memory for handles allocated to users sessions on Windows terminal servers is quite small and Microsoft told us to increase the registry values for SessionPoolSize to 60 MB and SessionViewSize to 120 MB. After a restart of the terminal servers the users were able to start a lot more instances of our application.
Kind regards
Kay Zumbusch
Hi Kay,
Thank you for informing us that the problem is resolved and providing details on this issue, it is appreciated. We are sure that this information will be useful for other customers.
Thanks,
Alex