minigui: win32 updates very slow

[WebFreak001]

check this code, any interaction with it or recreating checkboxes takes multiple seconds of unresponsiveness to load:

/+ dub.sdl:
dependency "arsd-official:minigui" version="~>10.1.0"
+/

import arsd.minigui;
import std.conv;
import std.stdio;

void main(string[] args)
{
	auto window = new MainWindow();

	auto layout = new VerticalLayout(window);

	new TextLabel("Count:", layout);

	int[] counts= [32, 64];

	auto dropdown = new DropDownSelection(layout);
	foreach (count; counts)
		dropdown.addOption(count.to!string);

	auto scroll = new ScrollableWidget(layout);
	auto list = new VerticalLayout(scroll);

	dropdown.addEventListener(EventType.change, (v) {
		foreach_reverse (child; list.children)
			child.removeWidget();
		if (v.intValue >= 0 && v.intValue < counts.length)
			foreach (i; 0 .. counts[v.intValue])
			{
				auto pair = new HorizontalLayout(list);
				new LineEdit(pair).content = text("Checkbox ", i + 1);
				auto cb = new Checkbox("active", pair);
				cb.addEventListener(EventType.change, (v) {
					writeln("change ", i, " to ", cb.isChecked);
				});
			}
	});

	window.loop();
}

[adamdruppe]

my suspicion here is each change redoes all the layout in n^2 time cuz each change of children redoes it for all remaining children.

i'm tempted to queue that to make it asynchronous like painting. but then various fields won't be updated immediately and that might be a breaking change... im not sure how relevant that will be...

[WebFreak001]

also on first interaction with the UI (checking a checkbox, changing input lines, etc) it seems to rerender everything because it lags again then

[adamdruppe]

hmm it works without lag on linux but the difference could still be that relayouter since in windows that's a heavier operation

[adamdruppe]

oooh i didn't check the msg in WM_COMMAND so it was running the change event on almost any interaction with the box. ok that's an easy fix. then the layouts redraw on mouse hover which is also just waste (the new Style thing assumed hover events matter by default but like now i have to remember to override it in tons of places... sigh that might have been a mistake) it much better already but still horrible cuz the scrollable widget seriously sucks and i came close to formally deprecating it in 10.0 but i use it for some things internally and ran out of time in replacing it. maybe i can fix it though.

[WebFreak001]

here is a video what it's doing: https://streamable.com/b5y7ij

[adamdruppe]

On Wed, Jun 30, 2021 at 07:02:42AM -0700, Jan Jurzitza wrote: here is a video what it's doing: https://streamable.com/b5y7ij

yeah it is already a little better but the initial change is still slow. prolly cuz of the n^2 movement causing a bunch of redraws and stuff. i'll still see if i can batch that somehow.

[WebFreak001]

I would also be fine if I could do it virtually and then submit it all at once to you. (Like working on a widget and then only when done adding it as child to the list)

I think that would be a better approach actually, although additionally also batching would make this easier for things like whole lists.

[adamdruppe]

new methods

                list.beginBatchUpdate;
                scope(exit)
                        list.finishBatchUpdate;

make a huge difference on this speed thing. so it coming together.

but the max height is still broken in all this. i clamp max height for individual widgets but when there's 64, no one thing goes over the limit but the rest do and then it breaks layout

adding a new native container window also helps the scroll and click stuff working.

so slowly making this not suck.

[adamdruppe]

no more weird visual artifacts, drawing fast. just overlaps if the window too small which is of course what scroll is supposed to handle!

[adamdruppe]

actually i think i can auto-batch it fairly effectively by just hooking it into the (required anyway) batched redraw event.

[adamdruppe]

I think I'll push live pretty soon, it is a LOT better than it was now though still a little slow to add/remove; you notice the lag but still. I think it is actually the remove all that is a bit slow but it actually works and isn't too terrible.