View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0037688||Lazarus||LCL||public||2020-09-02 19:45||2020-09-19 10:56|
|Product Version||2.1 (SVN)|
|Summary||0037688: Form Resize, Controls sizing very slow|
|Description||The recent changes that were done when I reported issue 37467, which correted the event not firing, has had a massive effect on resizing.|
attached is a test project that you can turn on/off whether application.processmessages is used after resize, and enable formbegin/end update during resize.
The difference is around 4 times slower in new svn
My apps have logic for resizing that alters what is shown dependent on size of form, and a smooth resize is paramount,
test app uses just panel,label,image anf button components, so you should see the implication of the update
|Steps To Reproduce||Run the attached application; using stable and monitor the time in ms it takes to re-scale the form, then run it on svn, it is about 4 times slower.|
|Additional Information||ps. Why can't I re-open the issue I had before?|
|Tags||No tags attached.|
|Fixed in Revision|
Form_events_1.zip (101,183 bytes)
Apologies the above app has a bug, not adjusting components as it should be.
form_events_2.zip is the one to use.
Results svn 63804
No Option =16, ProcessMessages=94, FormBeginUpdate=16, Both=94
Results SVN 63853
No Option =140, ProcessMessages=235, FormBeginUpdate=47, Both=172
Form_events_2.zip (101,030 bytes)
Just tested Rev 63888.
it has fixed that the form.resize is being fired.
form.OnResize appears now not to be re-entrent, if you run the attached test with rev 63888, and compare against rev 63556, you will see some big differneces in the time my re-size take to complete.
The attached project; now keeps track of how many time the on-reize is called when it is allready in the re-size code.
rev 63556 (resizing the form via the corner tab, slowly upto full screen and back again)
Use processmessages re-entrant called 48 times, max time in code 94ms average time in resize code 20ms
use ProcessMessages and Begin/End Update Re-entrent 88, max 94 avg 13
Use Begin/Endupdate Re-entrant 0, Max 16, Avg 3.
use None Re-Entrant 0, Max 31, AVg 5
Use processmessages re-entrant called 0, max time in code 344ms average time in resize code 141ms
use ProcessMessages and Begin/End Update Re-entrent 0, max 234 avg 37
Use Begin/Endupdate Re-entrant 0, Max 62, Avg 12.
use None Re-Entrant 0, Max 281, Avg 38
I get similar figures when testing on WIn/32/64 and linux Mint. Not yet tried on MacOS yet
Can anyone else confirm similar impacts?
You may think that its a strange test; but a few of my applications use the resize event to calculate what is displayed on the screen and in what location; based on the size of active form etc. These forms do not use anchor docking because visual components can be moved, made visible etc based on screen size and user preferences. Also they keeps a track if it in a re-entrant state so that any cpu/gpu intensive scaling etc can be ignored; until its not in a re-entrent state; it might complicated; but it does keep the application extrememly responsive and smooth. THought I would explain the issue.
Also the current way it works is not very compatible with Delphi
Form_events_3.zip (102,037 bytes)
||@josh, you tested with r63853. Did it cause the problem? The related issues have many revisions involved, you should mention here only the ones that affect this issue.|
|2020-09-02 19:45||josh||New Issue|
|2020-09-02 19:45||josh||File Added: Form_events_1.zip|
|2020-09-02 21:30||josh||Note Added: 0125304|
|2020-09-02 21:30||josh||File Added: Form_events_2.zip|
|2020-09-03 20:27||Juha Manninen||Relationship added||related to 0037467|
|2020-09-06 10:32||wp||Relationship added||related to 0037706|
|2020-09-18 23:34||josh||Note Added: 0125633|
|2020-09-18 23:34||josh||File Added: Form_events_3.zip|
|2020-09-19 10:46||Juha Manninen||Note Added: 0125640|
|2020-09-19 10:56||Juha Manninen||Relationship added||related to 0036127|