Resizing standard controls much slower in trunk and controls are shifting.

[Josh]

Hi

I have been trying to nail what is causing this behaviour, the resizing of standard controls and custom controls are much slower in trunk by a factor of at least 4.
also i have controls that are shifiting their position.

I have attached a project which will demonstrate this if you run it, it creates a multiple copies of the tbutton and timage ( this was done to visually show the problem),
I have created my own form.resize routine that iterates through the button and images ( from number 2, which is the ones created at form create, and positions them acording to the position of the initial tbutton/timage.
If you res-ze the form you will see odd effects, the app allows you to turn on app.processmessages, use formbrgin/endupdate and also allows you to set the creates controls anchors to either none [] or akTop+akLeft.

if you do this again other odd things happen, what is concerning is that the timage (master actually moves it position and theother follow it), which is odd as the app does not change its ordinates.

On my devel machine
using laz 1.6.5 and fpc 2.6.5 I get a reasonable rapid response of aroun 11ms, using trunk I get 66ms.
On a lower spec laptop trunk can give a figure of over 500ms to execute the resize, in laz 1.6 the same params i get about 60ms.
Running on a laptop highlighted a strange effect, its as though the components and panels are being re-drawn multiple times at slightly different positions then finally being drawn at  the correct co-ordinates.

I cannot use anchors in many of my apps as the postion, size of componentsare dependent on what user has selected and what best fits the screen ration, so some time controls may or may not not be visible, and dependent on the screen ratio some controls can be under others or to their side, and this has to be smooth and fast, it has previously, but something in trunk has changed.

If their is something happening in trunk, that is trying to auto alighn, rescale is their away to turn it off so the app can control what it wants to.

The app also keeps a track of how many times events are fired, this is interesting also as it appears trunk is somehow filtering some 'Duplicate' events from the teh message queue.

Apologies for the wall of text, but if you were to run this on various versions of lazarus I think you will get similar result and questions?

I have tested mainly on Windows, but the issue is also on Mac.

firev1 laptop trunk
firev2 laptop 1.6.5 2.6.5

[avra]

Laz 1.6.5 + FPC 2.6.5 is too far from trunk. You should test with previous official Lazarus 2.0.8 which comes with FPC 3.0.4 and current Lazarus 2.0.10 which comes with FPC 3.2.0 and report if results are the same as with trunk.

[JuhaManninen]

@josh, you reported it in September.
 https://bugs.freepascal.org/view.php?id=37688
Please find the guilty revision in trunk. Git with its local commit history and "git bisect" command help with that.

[wp]

I don't understand what you are doing although I looked at your demo provided. Why do turn the visibility of the controls an and off? Why do you write your own FormResize routine to layout the controls? There's a TFlowPanel in the LCL (well - maybe not in Laz 1.6.5) which does this automatically and runs much smoother and faster. And there are lots of calls to FindComponent which certainly result in a slowdown in time-critical code.

[Josh]

@avra
Tested with loads of version of stable, 1.6.5 was the oldest, issue is with trunk, lazarus fixes with 3.2fixes does not have the speed issue.
@wp
as explained the position/dimension of my controls will change dependent on resolution or screen ratio, also some of my controls are real-time graphical/image controls, so resolutioin is altered when change, these controls during resize are 'paused' the current image is scaled, then when resize is finished unpaused so as control can redraw itself from the data being fed to them. Also the text of controls are altered dependent on size of the  control, some times the control will have enough room for their full description and other times not ie,CVT becomes Check Valve Temp if the text appears underneath temp gauge; which can happen if enough screen real estate exists.
its not findcomponent, i have tested that by finding components many millions of times,no real difference between version.
i have experimented with tflowcontrol, but it is just another component; that would attemp to take control over where and how my components appear.
@juha
Yes reported it their and also  https://bugs.freepascal.org/view.php?id=37467, unfortunately they seemed to have stalled and new issues are appearing, time is not easily available to me to track where the issues are coming from' so hoping others can help here.

It is as though, something in the background is doing things when not asked to; to components when dimensions or events are fired. It could be the Hi Dpi thing, but I have this turned off and also have the scale option turned off, I also suspect that the event message cue mehanism has been altered to stop re-entrant to some events.

[avra]

Tested with loads of version of stable, 1.6.5 was the oldest, issue is with trunk, lazarus fixes with 3.2fixes does not have the speed issue.

Well, that shrinks revisions testing range a lot. I know that it is not easy and takes a lot of time, but as you can see so far it's only your itch and nobody else's, so I do not see any other way to solve it but to do what Juha suggested and find exact revision which cased the problem and report it.

[Josh]

my itch that has recently arrived in trunk (scratch sratch)

try creating a new project, place 2 tbuttons on form now turn anchors off on one button2, the button should stay at its placed co-ordinates, run the project, resize the form, and watch the result.

edit
turn off form scaled, and turn off lcl hdp in project options. ( just to try to elimanate scaling).

you can also add a label to form, and add the code to the button2.onchangeevent
label1.caption:='left '+inttostr(button2.Left)+'      top '+inttostr(button2.Top);

you will see it updates, so the control is being altered and the corresponding event is being fired.

[wp]

try creating a new project, place 2 tbuttons on form now turn anchors off on one button, the button should stay at its placed co-ordinates,

Maybe I completely misunderstand what you are doing. But by itself, this sentence is not correct: without anchors the button will follow the form at "half speed" when the form is resized. To see "full speed" add a third button with [akRight, akBottom]

[Josh]

oops my error, forgot that not setings anchors causes controls to go a wondering.

if you set the default anchor of the timage on the form, as these are duplicated when creating, it still is horrendously slow, and still controls are being altered during a form resize.

check the screenshot, look how they become allign, sometimes they will allign correctly more often it doesn't, it leaves a mess.

What is causing the time taken within the form.onresize routine to be so vastly different different in trunk?

[jamie]

I don't know but I think you should allow the LCL to manage your controls using the anchors etc..

in any case, you could use the "BeginformUpdate" at the start of that mess and when done for a single repaint "EndFormUpdate"

[Josh]

@jamie
The demo allows you to turn various things on off, including begin/end formupdate. This has no effect on Trunk taking 500% longer to do the same as previous versions.

[jamie]

I can't tell you and I am not going to bother..

I think we already covered this once before with a form loaded with junk..

why not try this prior to starting the recalculation of your controls if you are on a windows target

SendMessage(Form.Handle, WM_SETREDRAW, 0,0);

 // do all of your control relocations
// when done..

SendMessage(Form.Handle, WM_SETREDRAW, 1, 1);
                                                                        ^^ erase flag.
form.invalidate;

[Josh]

hi
applying

SendMessage(Form.Handle, WM_SETREDRAW, 0,0);

 // do all of your control relocations
// when done..

SendMessage(Form.Handle, WM_SETREDRAW, 1, 1);
                                                                        ^^ erase flag.
form.invalidate;

gives a slight speed performance, but als has a side effect, of not completed items during resizing, although when mouse released he final redraw will fill things that are missing.