domus

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).

Now, that's odd. As if someone forgot to uncomment before release...

No kidding!

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!

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.

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!

Merci bien, Patrick ! À la prochaine !

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.

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.

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.

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.

Yes, tried several times with GlobalUseSkia := True. Everything is noticeably slower then.

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.

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.

Have the same problem. Found a solution to this?

Hi, I'm using TBitmap.LoadFromStream in a background thread (TTask.Run), but it appears to be blocking the main thread (and UI), since I see pauses in execution when this function is executing. It's loading a PNG into a TBitmap. There is absolutely no interaction needed with the UI. The bitmap is not linked to any component. If this function needs to synchronize with the main thread for a part of its algorithm, is there an alternative one available that doesn't? Thx!

Imagine that meeting. Let's implement: TList: indefinite growth allowed; TStack: indefinite growth allowed; TQueue: indefinite growth allowed; TQueue<T>: indefinite growth allowed, but I propose we use "Push" and "Pop" instead of "Enqueue" and "Dequeue"! TThreadList: indefinite growth allowed; TThreadedQueue: STOP! We'll not allow indefinite growth! It's all up to the user now. Also, We'll be pushing and popping, not enqueueing and dequeueing. Also, unlike "ThreadList," we'll call this one "ThreadEDQueue." "That'll keep everyone on their toes!" Happy New Year!

I wrote "dynamically," by meant "automatically." My bad. When I tracked QueueSize when starting the debugging, I saw it grow along with the pushing of items, and by having made the mistake of believing the documentation, I thought the queue's size was growing automatically (along with the items being pushed) and dismissed it as being a possible cause. So I went down all the wrong rabbit holes. I know about Grow. I assumed, at first, that it entailed the reserved space for the queue before it automatically grew along with the pushed items, analogous to TList's Capacity property. But it doesn't grow automatically, of course, just to make life a tad more exciting. Cheers! Dom

Hello, Remy. You're absolutely right. I was assuming TThreadedQueue had dynamic size, like TQueue, but it's a fixed-capicity ring buffer, apparently. As an aside, do you know why its QueueSize property is returning the amount of items in the queue, contrary to the documentation, stating it returns the fixed size of the queue? (not that it matters, since I can keep the fixed size in a separate parameter, but it's misleading) Also, why are they using PushItem instead of Enqueue and PopItem instead of Dequeue? And, as a final question, why isn't there an option to make it grow dynamically? None of these are questions you're supposed to answer, of course, but just wondering... Thanks for making me dig deeper into this. Cheers, Dom

My goodness. The thing that was blocking everything was a TThreadedQueue. Days of debugging, just to find out this thing is absolutely unreliable inside a TTask (in the sense that it absolutely blocks the main thread when popping an item).

After quite a bit of back and forth with the o1 GPT model, it suggested using TBitmapSurface directly, like TBitmapCodecManager.LoadFromStream(strm, Surf) (where strm is the PNG stream), which it claims uses only the CPU, steering clear from any blocking caused by GPU access, but having tried that, I see no difference. Still on Delphi 11, but I could try Skia anyway. It's just that the last time I tried it, a while back, it seemed slower than the native FMX library (using D2D). Thanks!

Indeed, that's what I'm trying to find out. If it does, it kind of defeats the purpose of having it run in the background.

Does Graphics32 support FMX? Just stumbled upon Image32. Anyone know how it handles TBitmap streaming...?

OpenAI have introduced something that seems quite useful in getting a consistent, structured reply from ChatGPT: Structured Outputs. Is there a way to use it in Delphi, without reverting to Python? Just asking in case someone has already gone through the research, and slightly lazy on my part, admitted. Cheers, Dom

While the documentation site is down, would anyone know why it's a problem using an Int64 with an Sqlite database? Int64 values written to Sqlite Integer fields seem to be problematic (truncated to 32-bits). Manually changing all field properties to .AsLargeint, on the other hand, throws a "type mismatch" exception at application startup. All Sqlite integer fields are supposed to support 64-bit values. (don't bother, solved by manually using BIGINT in creation of table)