Leaderboard

Nothing strange at all but standard pascal behavior - compiler only sees what has been declared so far. Possible solutions: - change implementation order - declare in separate unit interface part - use forward

v3.4.0 Added StrokeColor property to TSkLabel; Added LetterSpacing property to TSkLabel; Added automatically Skia to uses when use controls in form; Added EncodedImageFormat property and MakeFromStream to SkCodec; Added MakeRawShader to SkImage; Added MakeImage to SkRuntimeEffects; Exposed DirectContext in TGrCanvasCustom class to run code on the GPU more easily; Fixed BackgroundColor property of TSkLabel; Fixed issue loading bitmaps from stream when using Skia in Vcl project; Fixed build script with python3 as default; Minor improvements and fixes. New StrokeColor property of TSkLabel Github: github.com/skia4delphi/skia4delphi Website: skia4delphi.org

Being reserved word only means that you cannot use those words as identifiers. It does not tell you anything what each reserved word represents in the language. If you are asking about coding style and why is string written in small caps, then being reserved word has a meaning in that context because there is a coding style rule (which you don't have to follow, of course) that says reserved words are written in small caps. When you are talking about string being an alias for UnicodeString then this describes its semantic - its behavior and what it represents. "string" describes default string type and its definition can change in different compilers. For instance, in Delphi 1 string was alias to ShortString, and in Delphi 2 - Delphi 2007 it was alias for AnsiString, and since Delphi 2009 string is alias for UnicodeString.

In Delphi string is separate data type and strings are not classes https://docwiki.embarcadero.com/RADStudio/Alexandria/en/String_Types_(Delphi) https://docwiki.embarcadero.com/RADStudio/Sydney/en/Fundamental_Syntactic_Elements_(Delphi)#Reserved_Words

If you follow a guideline that all reserved words (keywords) are written in small caps, then string which is a keyword should be written as "string".

The reason is that function GetDay(dt: TDateTime) doesn't yet know about the other overload. You either have to replace their order or, better, add a definition like you did when you added their definition in the interface section of the unit.

It's attached. I also put a screenshot of what it looks like under Delphi. If you try add any unit to one of uses sections it will be placed in wrong place. TestUnit.pas

@Rollo62 Eugene's idea (creator of FMX) is great. He creates regions with cached drawings, through his control, then it is the programmer who has to define where he will cache the drawings, and have moderation about it. Unfortunately I had some issues mainly with updating the drawings of some controls inside it, so I never used it in production. I'm very conservative when I think about third-party libraries. Some libs also partially solve the FMX performance problem, but they leave you hostage, since you have to change all your codes, use their controls, etc. This is the main difference, you implement Skia in your app changing only 1 line in dpr. The day you want to remove the library, just remove the line... About updates and development stage, we still don't have the best code design and there's still a lot to optimize, a lot, such as: using Vulkan on Android and Windows 10+, and using hardware acceleration in drawings inside bitmaps, etc. But one thing I can say, it's very stable, it's no wonder that today we have 0 issues.

@Rollo62 The replacement of the FMX graphic engine by Ski4Delphi graphic engine (which is done just by adding the line "GlobalUseSkia := True;" in the dpr), affects all the drawings in your app, whether the screen controls or drawings in TBitmaps. So even delphi controls like TRectangle, TCircle, and all others (even third-party controls) are now rendered on screen by the Skia-based Canvas. Everything is done automatically internally. With this, your entire application will automatically gain: - Performance (up to 50%) - Quality in drawings (everything is rendered with antialiasing, and maximum quality, producing smooth curves, no jagged edges) - Fidelity (there are dozens of bugs in the FMX render that do not occur with Canvas based on Skia, mainly involving Metal) - And other advantages

@Stefan Glienke I got a little 'nudge' that my reply above was rude and seems inconsiderate to your help in the past. I hope you didn't read it that way. I took your comment as if my benchmark was waste of time, but re-reading it, I see what you meant. Anyway, I think I was always appreciative to your help and expressed it in past topics. Don't feel like you need to help me in every topic, I have no problem getting no comments on my benchmarks, I take it as "nothing big is wrong with it" or "it's so wrong, it would take me too long to explain", I welcome both options, because they mean either I did something right or I'm slowly getting there. The 64bit projects will go through a lot of benchmarks, so I will probably post more observations like this one, so be on the lookout for something that peeks your interest, I will not be offended if you skip the rest. Also, come on, you can't say that Moe, Larry and Curly's reprisal of 'First!' comment wasn't worth at least a little chuckle at my expense... I know I did, he he.

I recently reached the age bracket that many would probably consider 'unteachable', so it's not on purpose. I was away from Delphi for a couple of months and now preparing projects for 64bit, so it's fun to do some benchmarking again. If I can make some good progress, like in this case reducing some process runtime by half a second, even better. This process is part of search feature, so user interaction feature, and any speed improvement is very useful because users notice them very quickly.

I'm sure you understand why. procedure TFooBar.SetValue(const AValue: TFooFoo); begin var Value := AValue.Transform; FValue := Value; end; Did you mean that there are better solutions? Sure there is but I think this is a case of preferring good enough over perfect.

Other advantages: Properties can be read-only. Since you can opt to have methods for the setter and getter of a property, you also have a place to monitor the activity of the said property - with a breakpoint that simply counts accesses, a method that logs the accesses, or an actual breakpoint Using the get method, a property can allow for lazy instance generation, so that if it is never used, the connected instance is never instantiated Using the set method - the validity of a property value can be decided on assignment, without needing that validation to be spread around on the calling code

And then there's this one about "Code Profiling, Optimization, Performance, and Memory Leaks" (in which the audio worked but the video didn't, so it's two hours of power point) which manages to completely avoid the topic of profiling...