Dalija Prasnikar

I don't know. The question is what do you get when you try enabling Vulkan. Do you have aliasing problem with Vulkan, too? Each of those checks uses completely different rendering technology. So Skia Raster canvas is a different one from Skia Vulkan.

How it works when you UseVulkan? I have done some experiments and the fallback for Skia is OpenGL while FMX without Skia uses Direct2D. I am getting much better performance with Vulkan on Windows.

What are your exact settings when the drawing is slow on Windows? All GlobalXXX values you are using?

If all Macs work fine, then this is not due to tile based rendering (or at least not significantly), probably unified CPU/GPU memory is more relevant here. Another possibility would be that there is some difference in FMX platform specific code. But I cannot comment on that as I never looked at it.

The question is whether they can do something about it at all. For start, Skia in Delphi operates on several layers of indirection (including some poor design choices) which also involve memory intensive operations on each paint (including reference counting). When you add FireMonkey on top that is additional layer. Now, all that does make Skia slower than it could be. But that problem exists on all platforms. ARM and especially Apple Silicon have better performance when it comes to reference counting, but that is probably still not enough to explain the difference. Some of the difference can also be explained with juggling memory between CPU and GPU on Windows as those other platforms use unified memory for CPU/GPU. However, my son Rene (who spends his days fiddling with GPU rendering stuff) said that from the way CPU and GPU behaves when running Skia benchmark test, that all this still might not be enough to explain observed difference, and that tiled based rendering on those other platforms could play a significant role. Another question is how Skia painting actually works underneath all those layers and whether there is some additional batching of operations or not. @Hans♫ Do the Macs you tested it on have Apple Silicon? If they do then they also support tile based rendering. As far a solutions are concerned, it is always possible to achieve some speedups by reusing an caching some objects that are unnecessarily allocated on the fly, those could be both in FMX code itself, or in how FMX controls are used and how many are them on the screen. I used to create custom controls that would cache and reuse some FMX graphic objects when painting instead of creating complex layouts with many individual FMX controls.

Even with class helpers available, I had to edit VCL source code in few places. And I still had to make a completely new implementations for plenty of stuff. Now, with time some things get fixed, some get improved, but there will always be things for which you would either need class helpers, which are no longer available.

Well, that discrepancy could have been solved with 1-based arrays. Delphi wouldn't be the first nor the last language having them. See: https://stackoverflow.com/q/9687039/4267244

That is in no contradiction with what I said, as TP started as extension of Standard Pascal. Anyway, 1-based string types never caused any problems until they introduced 0-based strings for mobile compilers and the whole hell broke lose.

This was due to Turbo Pascal legacy.

Each core has its own FPU. It is possible that some older multicore processors shared single FPU, but even in such case each thread would have access to its own "FPU data copy". If those values would be shared among threads, then different threads could trample upon results of other thread calculations.

FPCR is part of the FPU and its state is preserved during context switch. So each thread works with its own state that is independent of others. If you only handle floating point state directly through FPCR it will be thread-safe. Problem with Delphi is that it throws global variable into the equation and then handles FPCR with the help of that global in thread-unsafe manner, which can then leak "wrong" state into different thread.

FPCR can be set in a thread safe manner. it is just that Delphi RTL doesn't do that on Windows platform. David has written about it see and https://stackoverflow.com/a/27125657 I have also written about it in my book Delphi Thread Safety Patterns. Working with masked FPU exceptions is the norm across various languages. Also even before Delphi 12, all other Delphi platforms except Windows VCL has masked FPU exceptions. So if you had written FMX application it would have been working the same way it is working now across the board. So the best option is moving to the masked FPU exceptions as this will create the least amount of trouble for the future. Of course, if you are dealing with Delphi built DLLs which don't honor that, you will have to adapt. Another option is to unmask exceptions and proceed as usual, but doing that in multithreaded application is not advisable unless you also patch the RTL as it is not thread-safe. Even having masked FPU exceptions is not thread-safe, but it is much harder to trigger the issue and much easier to avoid RTL API that uses unsafe parts than with unmasked exceptions.

Well, the problem is technically in the LLVM, so blaming the LLVM is fine 😉 But again, also it is not technically a bug in LLVM, but merely lack of certain feature, which is not so easy to add at this time.

It is language related, more precisely compiler related (LLVM backend). The hardware part is related to exceptions that happen in hardware which cannot be caught by LLVM backend. Old Delphi compiler (Windows one which has custom frontend and backend) can catch those because it was designed that way. LLVM origins are in C++ which on language level does expect catching such exceptions, so there was a "design mistake" in there that is now very hard to change, to accommodate slightly different languages. Most common hardware exceptions are access violations (accessing nil or invalid memory) and floating point exceptions. See: https://dalijap.blogspot.com/2023/12/catch-me-if-you-can-part-ii.html Plenty of languages are designed around notion that if they encounter certain types of issues they should just crash the whole application instead of trying to recover. Now, such behavior reduces the chances of certain vulnerabilities, but on the other hand makes very hard to deal with certain scenarios, especially gracefully detecting and handling bad input data, and they put a lot of more pressure to the developer to imagine all kinds of potential failures and prevent them explicitly in code. So in Delphi (Windows platform) accessing nil pointer will result with exception which you can catch and handle, so you can write code that will not check for nil instance and just try to access it and if it fails you can have exception handler that will handle such situation without anything bad happening. On the other hand, if you have such code in Swift (which also uses LLVM) your application will crash and burn and you cannot recover from such error at all. You need to pre-emptively check whether instance is nil when you expect it might be to avoid accessing nil instance. In Delphi compilers with LLVM backend, you can still catch nil instance access and recover, you just cannot catch it in the immediate code block, but it must be in separate procedure or method and only outside exception handler can catch and gracefully handle such exception.

I would use TypeInfo instead of RTTI as it will be faster. This requires System.TypInfo procedure TMyThingy.SetEnumPropertyValue(const AValue: string); begin PByte(@FEnumProp)^ := GetEnumValue(TypeInfo(TMyEnum), AValue); end; You should pay attention on enum type size and use appropriate sized pointer when casting PByte(@EnumProp)^. This will also raise out of range exception if passed string does not match to any value in TMyEnum. You can catch that and set it to some default value if needed.

If you really need to have multiple references to an object, then use interfaces and ARC to manage lifetime. If not, then you will have to invent similar mechanism for managing the lifetime.

This is always the greatest benefit. Integer math is still faster. Just not that much. And division is still more expensive than multiplication. Anyway, when it comes to any optimizations, it always goes hand in hand with measuring. and making sure that you really need optimization in the first place and are not making a bad trade-off by complicating the code.

I have no idea what is in that book, but I doubt that it is very much obsolete. Math behind it does not change. Nor the fact that some operations will always be more expensive than others, no matter the CPU.

Since December Stack Overflow and other sites in the network have been spammed with AI generated answers which are usually incorrect while sounding plausible. To handle this problem moderators working with other users and Stack Overflow staff enacted the policy that bans all AI generated posts. Such posts are deleted and users can be suspended (usually for a week) for posting them. To get the better picture about the impact, we are talking about thousands of users and even more posts. See: https://meta.stackoverflow.com/questions/421831/temporary-policy-chatgpt-is-banned However, last week the company enacted another policy which still allows moderators to moderate AI generated content, but effectively does not allow them to to use any means necessary for detecting such posts. In other words they can remove posts mostly if user admits post is AI generated. Allowing AI posts on sites will effectively kill the sites and elected moderators have decided to take an action and go on strike, along with other users of Stack Overflow and other sites in the stack Exchange network. Strike is scheduled to start tomorrow on Monday, Jun, 5th. Unofficial announcement of strike on Stack Overflow (there will be another announcement on the main Meta tomorrow) https://meta.stackoverflow.com/questions/424979/what-has-happened-to-lead-moderators-to-consider-striking If you have Stack Overflow or other Stack Exchange account please support the strike and sign the strike letter at https://openletter.mousetail.nl/ Signing is made by automatic authentication with Stack Exchange network account through browser if you decide to sign. You will have to enter display name you want to be displayed on the letter as some people have different display names on different sites. Thanks!

This is classic AI spammer tactic. Post AI on random posts to make it look like user is actively participating, and then separately they also post blatant spam.

I never used that setting so there might be issue with that one. But, when you run the wizard at one point you will also have Three buttons under the settings tree: Update Migration, Version Migration, and Computer Migration. You should choose Version Migration when migrating form one version to another. It is probably better to export settings to file and then import after the installation. But even if you do that you need to make sure that you choose Version Migration. The fact that IDE was trying to load packages from older version is a signal that you have imported wrong settings.

Update migration is wrong option. It is used only for same version updates. You need to choose Version migration. 11.x and 12.x are not compatible,

You don't understand. They are implemented as interface based class. Without that implementation they wouldn't work at all. It is just that compiler hides that fact from us and automatically creates everything needed.

There would be no reason to change it, short of removing anonymous methods. Early design is discussed here http://blog.barrkel.com/2008/07/anonymous-method-details.html

Memory leaks as such are indeed not relevant for this discussion, but accessing invalid memory is the focus of this conversation and manual memory management opens up such possibility.