Jump to content

Dalija Prasnikar

  • Content Count

  • Joined

  • Last visited

  • Days Won


Dalija Prasnikar last won the day on May 20

Dalija Prasnikar had the most liked content!

Community Reputation

1351 Excellent

Technical Information

  • Delphi-Version
    Delphi 11 Alexandria

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. NativeInt is 64-bit on Win64 so Integer overload is not appropriate (too small) there. If you want to force it to Integer overload you will have to typecast Integer(NewLine.Count - 1)
  2. Dalija Prasnikar

    Stack Overflow Developer Survey for 2024

    The only correct answer is to write Oranges
  3. Stack Overflow Developers Survey for 2024 is live https://stackoverflow.com/dev-survey/start Let's put Delphi on the map
  4. Dalija Prasnikar

    Slow rendering with SKIA on Windows

    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.
  5. Dalija Prasnikar

    Slow rendering with SKIA on Windows

    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.
  6. Dalija Prasnikar

    Slow rendering with SKIA on Windows

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

    Slow rendering with SKIA on Windows

    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.
  8. Dalija Prasnikar

    Slow rendering with SKIA on Windows

    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.
  9. 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.
  10. Dalija Prasnikar

    Delphi and "Use only memory safe languages"

    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
  11. Dalija Prasnikar

    Delphi and "Use only memory safe languages"

    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.
  12. Dalija Prasnikar

    Delphi and "Use only memory safe languages"

    This was due to Turbo Pascal legacy.
  13. Dalija Prasnikar

    Disabled floating point exceptions are problematic for DLLs

    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.
  14. Dalija Prasnikar

    Disabled floating point exceptions are problematic for DLLs

    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.
  15. Dalija Prasnikar

    Disabled floating point exceptions are problematic for DLLs

    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.