-
Content Count
56 -
Joined
-
Last visited
Community Reputation
2 NeutralTechnical Information
-
Delphi-Version
Delphi Community Edition
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
Now, that's odd. As if someone forgot to uncomment before release... -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
No kidding! -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
Ohforcryingoutloud! I found the reason why it's so much faster in my project than in the demo! To put it in the demo's terms, I use arrRect[i].SetBounds(arrRect[i].Position.X + 1,arrRect[i].Position.Y,arrRect[i].Width,arrRect[i].Height) instead of arrRect[i].Position.X := arrRect[i].Position.X + 1 Check out the difference in speed! -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
At the moment, I'm trying to figure out why, in my project, with hundreds of TLayouts parented to a TForm, all positional and size updates of those layouts (inside the Form's BeginUpdate and EndUpdate) perform quasi instantly. This happens inside mouse events (panning and zooming (scrollwheel)). I haven't tried doing the same in a loop, but wonder that would make a difference. The nondeterministic nature of this observation annoys me, but I can't dwell on it, although it'll keep bugging me. -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
Thanks very much for going to the trouble of pinpointing the culprit! I know what to avoid now. It is doing this with all controls, right, not just TRectangles? Cheers! -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
Merci bien, Patrick ! À la prochaine ! -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
Be my guest! I tried to look for the issue in QP a few days ago, but got sent from site A to B to A, then not finding anything in either, and finally giving up. I do remember QP to work, back in 1972, but I'm getting the impression they changed the furniture down there, and now it's a hassle to just locate it. Probably my age. Thanks for confirming! I can now cancel that psychiatric evaluation appointment. At least for this issue. Btw, I have been using TThread.Queue quite a bit, but never considered ForceQueue. Thanks for making me look into that one. -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
No, of course not. This is not production code, it's just something to demonstrate the slow-down. Of course not. That's not what I'm doing in my production code, but here, to demonstrate the problem, it doesn't matter. Of course. Not using ProcessMessages in the production code. There it's reacting to mouse events, and, trust me, I'm using ALOT of parallel procedures to speed things up. The ProcessMessages is just used in this code to demonstrate the slow-down. It'd be similar if any other way were used. -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
unit DemoSlowBringToFrontUnit; interface uses System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.Controls.Presentation, FMX.StdCtrls, FMX.Objects, FMX.Layouts; type TForm1 = class(TForm) btn1: TButton; procedure btn1Click(Sender: TObject); private arrRect: TArray<TRectangle>; public { Public declarations } end; var Form1: TForm1; implementation {$R *.fmx} procedure TForm1.btn1Click(Sender: TObject); var i, j, x, y: Integer; //l: TLayout; begin SetLength(arrRect,961); // l := TLayout.Create(Self); //l.Parent := Self; //l.Align := TAlignLayout.Client; i := 0; for x := 0 to 30 do begin for y := 0 to 30 do begin arrRect[i] := TRectangle.Create(Self); // change to l to test for layout parent arrRect[i].Parent := Self; // change to l to test for layout parent arrRect[i].SetBounds(x * 30,y * 30,20,20); Inc(i) end end; for j := 0 to 1000 do begin BeginUpdate; for i := 0 to 960 do begin arrRect[i].Position.X := arrRect[i].Position.X + 1 end; EndUpdate; Application.ProcessMessages end end; end. Quick test to see difference between using TForm and TLayout as parent. If this performs quickly with TForm on your system, let me know, then I'll have to figure out why on earth it's crawling on mine! Thanks and cheers. Edit: this doesn't show the BringToFront problem. Here is a timing example of introducing BringToFront. Change following code: sw := TStopwatch.Create; sw.Start; for j := 0 to 1000 do begin l.BeginUpdate; for i := 0 to 960 do begin arrRect[i].Position.X := arrRect[i].Position.X + 1; arrRect[i].BringToFront end; l.EndUpdate; Application.ProcessMessages end; sw.Stop; ShowMessage(IntToStr(sw.ElapsedMilliseconds)) On my system, this takes twice as long to execute. -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
Let's say I have pinpointed it to BringToFront. To find this out, I used my own profiler and bug tracking tool, encapsulating every call with a cycle-precision timer, accumulating the totals over the application's lifetime. What I have not found out, is why it works so well now with a TForm as a parent in my applications, while it's dead slow in the example code. -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
Yes, tried several times with GlobalUseSkia := True. Everything is noticeably slower then. -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
Thank you, Dave and Patrick, for replying. During my effort to provide some code that reproduces the problem, I stumbled upon something that I had not experienced with 11.3, and may be the cause of the problem, but it only confuses the matter a lot more, for me. I wrote some code to create a thousand TRectangles and then reposition them in a loop, inside Begin/EndUpdates, of course. They were parented to the TForm. The arrRect[i].Position.X := arrRect[i].Position.X + 1 line took absolute aaages to execute. I then created a TLayout, parenting it to the form and reparenting all the rectangles to the TLayout. It now executes in a flash. The problem obviously lies with TForm's way to refresh itself and Z-order all its components. Something I never experienced with 11.3. The weird thing now, however, is that, in the code where I removed the BringToFront, everything is still parented to the TForm, and it now executes in a flash too. (another weird thing is that I had commented out this BringToFront line before, to test if it made any difference, and it didn't, but now it does). In any case, if you have any idea what might cause it to suddenly work fast with TForm.......glad to hear it! I'll keep investigating, but I lost quite a bit of time trying to pinpoint this thing, so it'll be in (obsessed) background mode. Thanks again. -
Extreme slow-down in Windows FMX app UI since upgrading to 12.1
domus replied to domus's topic in FMX
Wrongly attributed the problem to TImage. Culprit was the BringToFront procedure, which appears to be one million times slower in Delphi 12.1 compared to 11. -
Before I start digging deeper, I thought I'd ask if anyone experienced a big slow-down in the FMX UI in their Windows applications since upgrading to 12? It has become unusable in my case. Not using SKIA. If anyone has any pointers about easy fixes, very eager to hear them! Thx! Edit: anything change with TImage rendering? Just resizing and repositioning is extremely slow (especially large batches, even with Begin/Endupdate).
-
Have the same problem. Found a solution to this?