Rafal.B

NVIDIA RTX 3000 graphics card
In both cases, GlobalUseSkiaRasterWhenAvailable=False and GlobalUseVulkan=True.
In my opinion, it looks better when GlobalUseSkia = False;

I understand, thanks.

52 minutes ago, Dalija Prasnikar said:

The question is whether they can do something about it at all.

 

For start, Skia in Delphi operates on several layers of ...

Thank you for your substantive and extensive comment.
In one word, there is no reason to expect any improvement?

4 hours ago, Uwe Raabe said:

Looks similar to this report: https://quality.embarcadero.com/browse/RSP-42714

Considering my case, this is exactly the problem. 😞
I haven't noticed this report until now.
Thank you for pointing out this report 🙂
As you can see, the topic is not new, and EMB has not done anything about it (for now) 😞

I want to confirm slow graphics rendering using GlobalUseSkia=True.
I create SCADA applications. There's a lot of graphics there. To make it 'nicer' I use animations. Unfortunately, with the GlobalUseSkia=True option it works terribly slowly (2-3 fps). With the GlobalUseSkia=False option it is much better. However, I would expect much smoother operation.
This problem also occurred in D11.3
I use equipment:
HP ZBOOK G7 i9; Quadro RTX 3000

Hardware is probably not the problem here.

I just installed Delphi 12.1
and no problem, everything works properly (fast). 👍

I reported this problem to technical support.
They confirmed its occurrence. They asked me to wait until the QP portal is launched and report it there.
I wonder if I'm the only one who has this problem?

I found the culprit in this situation. It is: 
StringGrid -> Options -> Header
Disabling this option causes the data to display as quickly as in D11. Of course, the Header is not displayed then.
I compared the "FMX.Grid" file with D11 and D12.
There are a lot of changes regarding Header.
Unfortunately, something went wrong with Embarcadero, and I have no way to report it to them because QP still doesn't work.

Knowing what the problem is, the thread should be in the "FMX" topic.

This video shows option 3 on the D11
Works as it should.

I recorded a video showing the problem:
Clean install of Windows and Delphi 12
The video shows ADOQuery activation in three situations:
1 - No StringGrid links to BindSouce
2 - StringGrid connected to one BindSouce field
3 - StringGrid connected to all BindSouce fields
The problem is option 3.
As you can see, the problem is not the speed of the connection to the database, but what happens in BindSouce and StringGrid with a larger number of fields in the record.
The number of fields in the record is about 90. The types used are: nchar, datetime, tinyint, int, float and nothing else.
I would like to point out that this problem does not occur on D11.

It's the same application.
I uninstalled D11 and installed D12.
I didn't change anything in the application itself.
Application in the FMX environment, Windows 23H2.
As a test, I installed D11 on a virtual machine.
And everything works quickly there as it should.

I noticed that right after starting D12, the first activation of ADODataSet.Active=True happens quickly (like in D11), and each subsequent activation is slower.
The same thing happens when the program is executed (fast first, then slowly);

Hello everyone.

I have a classic layout (Windows-FMX, MSSQLExpress database):
ADODataSet -> 'Bind Visually' -> StrinGrid
ADODataSet.CommantText = 'SELECT TOP 100 * FROM xxx' (regord contains about 90 fields)

The database contains approximately 60,000 records.
At design time, in Delphi 11, selecting ADODataSet.Active=True causes data to appear in the StrinGrid in ca. 0.3-0.5 sec.
In Delphi 12, this operation takes 5-7 seconds.
Of course, it behaves identically during execution time.
I've already tried:
I imported the database into MySQL, I used FireDAC components:
FDConnection -> FDQuery -> 'Bind Visual' -> StrigGrid. Unfortunately, the effect is the same.
However, when editing FDQuery (FireDAC Query Editir), after pressing 'Execute', the data in the 'RecordSet' tab appears immediately.
This means that this delay occurs within 'Bind Visual' -> StrigGrid.

What's changed in D12?
I have no idea how to solve this.
Such a long delay is unacceptable to me.

Embarcadero boasts that it fixed this problem in patch 12.1.
Unfortunately, only half. It works fine at runtime (that's all, I managed to fix it myself a long time ago).
At design time, the problem still persists.
To check this:
in the project I attached to RSP-44319, select Button1, Button2 and Button3 at the same time.
Then, in the Object Inspector, set the "Visibe" parameter to False.
I'm getting the error "List index out of range (3). The range of TList<FMX.Controls.TControl> is 0”2”.

I have my own TFrame based components and I often use TFlowLayout there.
The visibility of these elements is set using the appropriate "property" added.
Opening a form containing such components always resulted in this error.
To work around this problem, I placed an additional element (e.g. Button) with dimensions 0.0 on the TFlowLayout.
However, when executing "not (csDesigning in ComponentState)", I remove this element so that everything is displayed correctly.

But that's not how it's supposed to work. 

Unfortunately, quality.embarcadero.com doesn't work and I have no way to report it.

Erratum:
A downloadable version has just been released:
"RAD Studio, Delphi, C++Builder 12.0 Inline with patch 1 ISO"
I uninstalled the previous version of D12 with a separate patch and cleaned the directory.
I downloaded the new version, installed it and IT WORKS CORRECTLY 🙂
I'll test it again, but it seems ok.

Hello everyone.
I reported the issue to QE https://quality.embarcadero.com/browse/RSP-43299
However, I don't know if and when they will deal with it.

A quick review indicates that the problem is the "TFlowLayout.DoRealign" routine in the "FMX.Layouts.pas" file.
The extra few lines of code (not present in 11.3) cause the problem.

Fixing this issue in your own project by adding a modified "FMX.Layouts.pas" file to the project works.
Once compiled, the program runs without any problems.

For me, the bigger issue is design time.
Opening the form for editing permanently generates errors:
"... List index out of range (2). Range of TList<FMX.Controls.TControl> is 0"1.
Ignore the error and continue? NOTE: ..."

I think "c:\program files (x86)\embarcadero\studio\23.0\bin\dclfmxstd290.bpl" is responsible for this
Is there any way to solve this problem in-house, faster than Embarcadero?

I worked with Delphi a long time ago, it was version 4.
I don't know all these new things and intricacies yet, so please forgive my ignorance 🙂