Description Anton Krug 2018-11-05 12:41:19 EST

When plugins based on CDT use the drop-down menu with many entries the whole panel freezes for ~30 second on each activation. This behaviour is not present on GTK2 (on GTK2 it's instant) and it's not depending on hardware (tested with 32core machines, with multiple i7 machines, all 32GB of RAM, SSDs, the hardware is not the issue).

For example, GNU MCU Eclipse plugins have this issue, the feature ilg.gnumcueclipse.managedbuild.cross.arm has the plugin.xml which is using CDT's build definitions

<plugin>
	<extension-point
		id="toolchains"
		name="Extra toolchains"
		schema="schema/toolchains.exsd" />
	<extension point="org.eclipse.cdt.managedbuilder.core.buildDefinitions">
		<managedBuildRevision fileVersion="4.0.0">
		</managedBuildRevision>

....

		<tool
			id="ilg.gnuarmeclipse.managedbuild.cross.tool.base.arm"
			isAbstract="true"
			name="ARM32 Targets common options">
			<option
				id="ilg.gnuarmeclipse.managedbuild.cross.option.base.arm.target.family"
				isAbstract="true"
				name="%option.target.arm.family"
				valueType="enumerated">
				<enablement type="UI_ENABLEMENT|CMD_USAGE">
					<checkOption
						holderId="ilg.gnuarmeclipse.managedbuild.cross.toolchain.base"
						isRegex="false"
						optionId="ilg.gnuarmeclipse.managedbuild.cross.option.architecture"
						value="ilg.gnuarmeclipse.managedbuild.cross.option.architecture.arm">
					</checkOption>
				</enablement>
				<enumeratedOptionValue
					command="-mcpu=arm1020e"
					id="ilg.gnuarmeclipse.managedbuild.cross.option.arm.target.mcpu.arm1020e"
					name="arm1020e">
				</enumeratedOptionValue>
				<enumeratedOptionValue
					command="-mcpu=arm1020t"
					id="ilg.gnuarmeclipse.managedbuild.cross.option.arm.target.mcpu.arm1020t"
					name="arm1020t">
				</enumeratedOptionValue>
				<enumeratedOptionValue
					command="-mcpu=arm1022e"
					id="ilg.gnuarmeclipse.managedbuild.cross.option.arm.target.mcpu.arm1022e"
					name="arm1022e">
				</enumeratedOptionValue>

....

There are around 100 entries in the CPU target menu and there are other dropdown menus as well. Is there something inherently slower and non-efficient when big lists which have to scroll outside the screen are generated in GTK3?

Noticed from other GTK2 related bugs that there is a notion to remove GTK2 and move forward to GTK3 and report any showstopper for converting into the GTK3. I would say this is a showstopper as the plugin works perfectly with GTK2 and yes the plugin is making more entries than a typical plugin would do. But it's supporting a lot of targets/cpus and there is no good way to group/simplify them either. So the list is large, but still manageable, just it's surprising that GTK3 version almost falls apart with ~100 entries when the widget is bigger than the screen and user has to scroll through them. 

Probably there could be a similar problem if the CDT GTK3 dropdown would have to populate a timezone selector with all Countries/Cities.