Leaderboard

Seems that this issue was resolved with this patch: https://blogs.embarcadero.com/rad-studio-12-3-april-patch-available/ SInce yesterday it was available on Getit and now also in the EMB portal.

A image showing what "rendered incorrectly" looks like would make it a lot easier to confirm reproduction.

The PegTop track and range bars are quite nice and easy to use: https://www.pegtop.net/delphi/components/common/screenshots.htm ...and there's couple in the SO post: https://stackoverflow.com/questions/4387690/component-similar-to-trackbar-to-enter-a-range-of-values ...and if you can wait a week or so I will be releasing one of my own (based on Graphics32 though). I have the track bar part completed so I'm starting on the range bar part now. DevExpress also has a range bar and I believe TMS has one too. Personally, if I weren't writing my own 🙂, I would go for the PegTop range bar; I have used it with success in many projects.

To disable Android +15 default edge-to-edge behavior, you can add the android:windowOptOutEdgeToEdgeEnforcement="true" attribute to your app's theme. This will prevent your app's content from extending into the system bars (status bar and navigation bar). https://developer.android.com/develop/ui/views/layout/edge-to-edge Example: Add the following to your project's styles-??.xml file: <style name="AppTheme" parent="@android:style/Theme.Material.Light.NoActionBar"> .... <item name="android:windowOptOutEdgeToEdgeEnforcement">true</item> </style> As Google mentions, this solution is temporary. Delphi Athens 12.3 already provides this solution in its styles-v35.xml file.

Note that is the wrong inner loop statement. It needs to go a level deeper. FixItem (aMenu.Items[I].items[k]);

Fixed in D12 V1.2.0.B40 (32 and 64 Bit) Will check what i can do, But it takes a while, i'm still busy with other tasks at the moment.

Well that is a new hell: the forum screws with the image. Also can't seem to delete the image I attached which ended up showing the same issue - size and bit depth messed with by the forum. Looks like it is display issue - click the image to bring up large view, click the large view to bring up a fuller view - now that shows the original uploaded image which you can right click and save image as .. to get the proper bit depth and resolution that was uploaded. If I load the image in your first post which is a 23kb 500x500x32 PNG into a TImage using the IDE it looks normal. Note the image itself does have gray pixels around the edges and borders of the squares - it is not black and white. The 2kb 912x912x1 PNG in the DFM does display oddly both on the form and in the IDE image property editor. In Windows explorer and other image editors I tried it looks normal. It has only black and white pixels. So the IDE does seem to have an issue with the 1 bit per pixel PNG. Can work around it by using a higher bit depth it seems but Delphi should really be fixed as the IDE exhibits the same issue. Attached is the 912x912x1 image re saved using MS Paint as a 9kb 912x912x32 PNG which works fine as well.

I said this before and I say it again - nobody should care how long the compiler churns on producing a release config build. Also: the FE is still written by Embarcadero and I don't know how much time is spent there compared to the LLVM BE and how much of that could be improved by tweaking some settings. Given their usual attitude of "making it barely work" and leaving optimizing for later until everyone and their cat/dog complains and then waiting even a few years longer until tinkering around the edges I can only imagine how well done the FE is. Also, keep in mind that the Windows compilers regressed heavily with all the new language features introduced in the past 15 years and that it was mostly due to the efforts of Andreas Hausladen that we gained back some of that speed in the recent versions while still being way behind what it could be imo. Currently reading through the thread (not done yet but just leaving my thoughts as I go through) and this comment was interesting: Interestingly later someone comments that if you compile a different project it turns around into the opposite - and then there is this statement: This is something I have actually seen with the non-Windows Delphi compilers: when I throw some generic-heavy code at them they take a ridiculous amount of time to compile - and some of the optimizations done by Andreas Hausladen actually resolved around generics. I would not be surprised if such an issue still exists either in the BE or in the LLVM code when generating debug symbols due to all the long full-qualified type names.

I was not sure about the sarcasm, but decided to reply, so that someone does not believe it blindly 🙂

Not according to Embarcadero. According to Embarcadero Delphi is blazing fast because it uses native code. We all know that to be absolute marketing BS and in fact Delphi compilers produce shitty code that often runs very slowly. Yes, my original post was sarcasm.

Delphi produces native code, and therefore is fast

That's for sure. We could even use more things and types from Spring4D. The main problem, actually - besides some time to integrate - is the deploy of it. Installation is already complex, it's rather complex to add Spring4D as a dependency, worse, as an optional dependency. That's why I'm really looking forward to @Vincent Parrett's DPM, when it's ready, we could deploy several different packages, and it will just download and install whatever dependencies it needs.

If it at least would produce binaries that are faster than what classic compiler for Windows produces ... But due to their currently super old LLVM version (hopefully they upgrade that once they are done on the C++ side which personally I could not care less about), they apparently had to turn off some important optimization steps which causes the binary produced by the Linux compiler to be approx as good as -O0