Very slow painting many components LCL/win32

[marcov]

I'm making a substitute for an older VB app that has 10 rows of about 15-20 components on a form. (see picture)

For familiarity I made one row in a TFrame, and then instanced that 10 times. The form itself also features a TFrame (so nested TFrame use)

However the result repaints visibly (1-2s) every time it is focused, from bottom up from roughly the line where the components start( which I suspected the number of components). The initial paint is a bit slower than reshowing the form.

I tried playing with turning doublebuffer and scaled properties on or off, and the hidpi setting in the manifest.

Anybody knows what this can be or how I can accelerate this to normal behaviour? (very slow painting)

p.s. I know it looks horrible, but it is just the initial rough component placement, and I ran the program to inspect the results when I noticed

[Martin_fr]

Interestingly that this worked under VB...

IIRC there somewhere is a bug report about an issues with something when there are hundreds of controls.

And I made a test app (don't have it anymore) just creating an array of buttons (IIRC 20*40 or similar) directly through win api (no lcl at all). And Windows would go bonkers, resizing the form a few time, could freeze my entire desktop for up to 30 secs.

[KodeZwerg]

I just can guess that on Windows a TFrame encapsulates its own message queue, so when you got 50 or more TFrames on it, their resize/repaint message queue can be triggered for a lot of different reasons and also can end in some kind of infinite loop, ie: MainForm trigger a repaint/update message, TFrame do its job and manipulate MainForm what again trigger TFrame and so on.
Never tested, just a theory.

[KodeZwerg]

Anybody knows ... how I can accelerate this to normal behaviour? (very slow painting)

Instead of using TFrame, use a simple Panel and copy/paste it, I am curious if it be a speed up, my belly would say yes.

[bobby100]

@marcov
I also have a similar situation on Windows, but it works perfect on Linux with QT5 widgetset.
I have a couple of tabs, with some 50 sliders on one of them. Changing the tab shows the same effect you described (the painting begins on bottom right, and ends on top left corner of the tab), and it is so only on Windows. As I said, on Lin/QT5 works perfect.

Edit: the sliders I use are from EyeCandy package.

[marcov]

It is not windows, or a windows tuning issue(hence why I tried the scalable doublebuffered, hidpi etc properties), since in Delphi this is also pretty normal.  To be absolutely sure, I'll try to test at work with Delphi this week. The core framework happens to be the same, so with a bit of creative lfm->dfm that might work

Martin:
these are <200 controls, not extremely excessive I think. Could you reproduce it without tframes also? Then at least we know it is not related to that.

KodeZwerg: I already tried the panel trick. Both the pane on which the tframes are instantiated as in the per row frame, all controls were put on a tpanel -> no difference.  I remembered that this caused repaint issuesi n Delphi with tframes.

[Martin_fr]

Martin:
these are <200 controls, not extremely excessive I think. Could you reproduce it without tframes also? Then at least we know it is not related to that.

The Issue I had was
- several 100 controls
- without frames
- issues when resizing the containing form

I just mentioned it as it may be that there is a limit of controls that windows handles well.

[marcov]

1. I'll test the Windows hypothesis with Delphi (mostly a dual compile codebase, so it can be relatively 1:1 comparison) and report back.

2. the Windows have window style wsmaximized, which could also be related (the framework was meant for machine firmwares)

[Thaddy]

It all boils down to beginupdate/endupdate, nothing else. Just use that in the container, not the controls.

[marcov]

There is no update code. It is all designtime. Of course there could be such mistake in the LCL code tho.

[SymbolicFrank]

I had the same problem with a cash register app, with a few hundred buttons. Ok, it had to run on minimal hardware. I switched to using BGRAControls to make it snappy (although I had to write much of the functionality of the controls myself).

I also made something like that in Delphi, ~15 years ago, like a kind of DIY TDrawGrid (with pictures), which also was pretty slow on redraw.

Both on Windows 32-bit.

[marcov]

FYI: this weekend I finally had a bit of time and ported the lfms to Delphi where I could test it with a similar application. (the original app is laz only).

Result: same, i.e. it apparently is not Lazarus.

[big_M]

@marcov

I also have troubles with win32, and I was wondering why it renders so terribly. I don't have far that many components in my project, but the UI is still generally very slow. However that's only the case on Windows 10. On Win7 the same program is butter smooth... Would be interesting to see if your app is faster on a Win 7 machine as well

[440bx]

Result: same, i.e. it apparently is not Lazarus.

Figuring out the cause of the slow painting can be a bit difficult.  When faced with that kind of problem the first thing I do is use spy++ to monitor all the window messages and pay close attention to where delays occur (which messages are/were involved.)

Sometimes, it also pays to run the app under an API spy.  Rohitab's api spy is a reasonable choice.

Usually, that's sufficient to figure out the cause.  If the above fails then, if you have SoftICE and the program runs under XP, run it under XP and break into SoftICE when the delay occurs, that will show you where the problem resides.

HTH.

[zeljko]

@marcov
I also have a similar situation on Windows, but it works perfect on Linux with QT5 widgetset.
I have a couple of tabs, with some 50 sliders on one of them. Changing the tab shows the same effect you described (the painting begins on bottom right, and ends on top left corner of the tab), and it is so only on Windows. As I said, on Lin/QT5 works perfect.

Edit: the sliders I use are from EyeCandy package.

Can you test with Qt5 under windows ? Is there any difference between win32 and qt5 widgetsets on windows ?