View Issue Details

IDProjectCategoryView StatusLast Update
0037706LazarusIDEpublic2020-09-12 11:14
Reporterwp Assigned ToJuha Manninen  
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version2.1 (SVN) 
Summary0037706: [Regression] IDE extremely slow when adding a new control to a heavily populated form
DescriptionThis is a follow-up to issue 0037595 where I reported slow response of the menu editor in trunk versions beginning with r62635.

Working on a project in which the main form contains a large number of controls I noticed that the issue is more general. When a new control is added to this form in the designer from the palette the border of the new control is drawn and the IDE remains unresponsive for some time. This time increases with the number of controls already on the form. When some cirtical control count is reached usefull working with this IDE becomes impossible.

This behaviour was introduced in r62635, reverting back to r62634 the new control added appears completely immediately, and there is only a very short delay.
Steps To ReproduceTry the demo program ImgViewer which comes with Lazarus (folder (lazarus)\examples\imgviewer). Load it into trunk (after r.62635) and add a TButton from the palette - I counted the time: about 40 seconds until the IDE was responsive again. And this is for a form which is not too heavily populated.
Additional InformationI have several trunk versions on my system (32 bit vs. 64 bit, FPC 3.2.0 vs 3.04.) - they all behave in the same way; therefore, I'd exclude the possibility that my trunk version is damaged in some way.

I tested only on Windows (WIn 10).
TagsNo tags attached.
Fixed in Revision
Attached Files


related to 0037595 closedJuha Manninen Menu item drawing issue during adding a menu separator 
related to 0037688 new Form Resize, Controls sizing very slow 
related to 0037593 closedJuha Manninen IDE becomes non-responsive when adding controls to heavily populated form. 


Juha Manninen

2020-09-06 00:54

developer   ~0125400

I don't think this is related to 0037595. It was solved by r63802 and r63803 which modified only MenuEditor.

Maybe this is related to 0037688 which also happens on Windows. Somebody else should fix that. My development environment is not Windows. Reverting guilty revisions is difficult, too, because there are many affected issues.


2020-09-10 15:13

reporter   ~0125461

Hi Juha,

I have just installed Linux Mint on VM, and the issue is there with linux as well.
I have also tested on my mac Mini; with same versions as outlined in issue 37688

It is much slower than previous version.

So it is not windows specific.

Juha Manninen

2020-09-10 17:29

developer   ~0125462

Is it caused by r63842? I will test it soon, too.


2020-09-11 00:01

developer   ~0125468

Last edited: 2020-09-12 11:04

View 2 revisions

I wondered why nobody else is seeing this massive issue on Windows. Since my development Win PC is torturing me with blue screens recently i installed Laz trunk on a Notebook, also with Win10 (which never had seen Lazarus before) - and: the issue is gone. So I am inclined to close the issue from my part -- and I'll have to fix my PC; of course, I cannot speak for the observation reported by josh. On the other hand, it is hard to believe that PC issue like damaged system files, hardware etc, disappear when I revert the trunk revision to r62634.

jamie philbrook

2020-09-11 01:07

reporter   ~0125469

   If you were able to remove the issue by reverting I would say there is still a problem. So I wouldn't throw in the towel yet on your end.
 It's possible your laptop is simply out performing enough to hide it and different video configurations can also be causing differences of operations.

You should install one of the official releases like 2.0.10 and see how that works with a large count of controls on your ailing PC because if Laz IDE or Large number of controls in a LAZ app is the only thing in your PC that is crawling like that, I would say something is still wrong.

 I don't run the trunk because I've never succeeded in being able to get any one my PC's at this location setup to sync with the files without all sorts of issues.

Juha Manninen

2020-09-11 09:09

developer   ~0125473

Last edited: 2020-09-11 09:16

View 3 revisions

@wp, is this possibly a duplicate of 0037593?
It was fixed a long time ago in r63791 and r63792.

@josh, adding a new control to a form is different from resizing a form.
Are you sure you can reproduce this issue, or are you explaining issue 0037688?


2020-09-11 11:21

developer   ~0125476

> @wp, is this possibly a duplicate of 0037593?
> It was fixed a long time ago in r63791 and r63792.

I know. But since I observed the issue of 0037593 with the main menu I wrote a demo program using a menu, and thus you fixed an issue related to a menu. But what if the real issue introduced by r62635 is still unsolved?

I am unclear what leads to the issue reported here. As noted, a clean installation of Laz trunk (with FPC3.2 taken from Laz 2.0.10) on a rarely used old Win10 notebook does not show the issue. On my main development machine I did a clean trunk installation, too, the issue persists but to a smaller degree: adding a TButton to the imgViewer example project takes 9 sec in the fresh installation ("fresh = after "make bigide") while it takes 16 sec in my normal installation.

Since the normal installation contains also the packages that I work on, the number of packages/components installed could fold into this issue. So, I added JVCL (which contains tons of components) to the fresh installation and the test time increased from 9 sec to 12 sec. Alternatively I uninstalled JVCL from the normal installation and the test time decreased from 16 to 13 sec. For comparison: the trunk installation of r62634 takes only 1-2 sec, with or without JVCL (similar to Lah 2.0.10 - your question, jamie)

So, I think it can be concluded that the time for the IDE to become usable after adding a button to the ImgView demo on the affected installation depends also on the number of components installed.

Still not clear what makes the difference in the notebook installation, it is always faster than the PC and there is only a marginal change on adding JVCL. There are some unmentioned differences, though, which still have to be checked: The notebook does not yet have the 2004 update of Win 10 (the PC has), and the notebook installation is 64 bit, while my workhorse installation on the PC is 32 bit.


2020-09-11 12:51

reporter   ~0125477

I am wondering whether you are hitting the amount of GDI object handles that windows handles per sesion ( you can alter this). IIRC the default is around 10K, also IIRC windows itself has a limit of 64K Object Handles.

Each UI Control in a Form is allocated at least one User Object Handle.

You can use task manager to show the amount of gdi handles (although other third party utilities do a better job). Open TaskManager Click the Details TAB and look under the Handles Column.

jamie philbrook

2020-09-11 23:35

reporter   ~0125493

I just had 2004 Win 10 updates on a I5 Win pro and I5 Home..

Tested with 2.0.10 release, 2.0.8, 2.0.6 and 2.0.4 with a app that has lots of controls on the form. they all work great and the ide isn't really having any issues different now than it ever did. I get a 1..2 sec delay max on most OI interactions with a densely populated set of forms.

  The only Delay I get and its always been there is when I drop the first initial control on a form when firing up the IDE. It could be a blank form and it does not matter.
but after that, it streams along just fine.


2020-09-12 11:02

developer   ~0125502

Last edited: 2020-09-12 11:14

View 2 revisions

I know - the issue does not show on any release version, only on trunk after r62635

Assuming I am hitting the GDI object handle count limit, then why don't I when I revert trunk to r62634 (this last revision which was ok)?

> I don't run the trunk because I've never succeeded in being able to get any one my PC's at this location setup to sync with the files without all sorts of issues.

Install TortoiseSVN. Create a folder for Laz trunk (c:\laz-trunk), right-click the folder, select "SVN checkout" and enter the Laz trunk repository URL ( - download the trunk sources. Write a batch file which (1) sets the path to a folder with a valid fpc.exe 3.2.0 (or 3.0.4), and (2) calls "make bigide". Execute the batch. When the process is finished add a file "lazarus.cfg" to the Lazarus folder (c:\laz-trunk\lazarus.cfg) with the content "--primary-config-path=path_to_lazarus_config_folder" (adapt "path_to_lazarus_config_folder" to your situation). Run Lazarus - the introductory dialog urges you to define the location of the fpc.exe to be used and where to find the debugger - use data from an existing Laz 2.0.10 installation. Finished. I did this many times, and it works.

Issue History

Date Modified Username Field Change
2020-09-05 12:37 wp New Issue
2020-09-05 12:37 wp Relationship added related to 0037595
2020-09-05 12:38 wp Assigned To => Juha Manninen
2020-09-05 12:38 wp Status new => assigned
2020-09-06 00:54 Juha Manninen Note Added: 0125400
2020-09-06 10:30 wp Assigned To Juha Manninen =>
2020-09-06 10:32 wp Relationship added related to 0037688
2020-09-06 12:32 Juha Manninen Status assigned => new
2020-09-06 12:32 Juha Manninen LazTarget => -
2020-09-10 15:13 josh Note Added: 0125461
2020-09-10 17:29 Juha Manninen Note Added: 0125462
2020-09-11 00:01 wp Note Added: 0125468
2020-09-11 01:07 jamie philbrook Note Added: 0125469
2020-09-11 09:07 Juha Manninen Relationship added related to 0037593
2020-09-11 09:09 Juha Manninen Note Added: 0125473
2020-09-11 09:10 Juha Manninen Note Edited: 0125473 View Revisions
2020-09-11 09:16 Juha Manninen Note Edited: 0125473 View Revisions
2020-09-11 09:17 Juha Manninen Assigned To => Juha Manninen
2020-09-11 09:17 Juha Manninen Status new => feedback
2020-09-11 11:21 wp Note Added: 0125476
2020-09-11 11:21 wp Status feedback => assigned
2020-09-11 12:51 josh Note Added: 0125477
2020-09-11 23:35 jamie philbrook Note Added: 0125493
2020-09-12 11:02 wp Note Added: 0125502
2020-09-12 11:04 wp Note Edited: 0125468 View Revisions
2020-09-12 11:14 wp Note Edited: 0125502 View Revisions