Leaderboard

Well, we are the most important...

Hi, I have ported SpkToolbar from Lazarus to Delphi. Here is the screenshot: You could download here: https://github.com/nglthach/SpkToolbar4Delphi OT: I'm looking for a remote Delphi developer position, if you would like to hire me, please contact via PM! Thanks!

@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

@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.

Better Translation Manager https://bitbucket.org/anders_melander/better-translation-manager The Better Translation Manager (BTM) is a replacement for the Delphi Translation Manager a.k.a. the Integrated Translation Environment (ITE) and External Translation Manager (ETM). Why is it better? Well, for one thing, it's free but more important; It actually works - unlike the ITE/ETM. Why? The standard Translation Manager that ships with Delphi today was originally an individual product known as the Borland Translation Suite. With Delphi 5 it became a part of the enterprise edition. The Borland Translation Suite showed great promise but unfortunately it never evolved from its roots as an external tool and has always been hampered by severe bugs that made it completely unusable in practice. As a result nobody uses it. This can be witnessed by the plethora of homegrown and commercial alternatives. The great benefit of the standard translation system is that it just works (this is the system itself I'm talking about, not the tools. The tools suck). Apart from the requirement that you must use resourcestrings you don't need to do anything special when writing your code. At run time you just place the compiled resource modules in the same folder as your application and the Delphi Run Time Library automatically takes care of loading and using the translations based on the current Windows user interface language. Anyway, since Embarcadero has now finally admitted that they are never going to fix the Delphi Translation Manager and instead recommend that we find alternative solutions, I decided that it was time I solved this little problem once and for all. The core functionality of the Better Translation Manager was written in two weeks during my summer vacation in Italy 2019. Amazing what you can do with a little pasta! Features Does not require any changes to the source code of the application being translated. Works with the existing standard Delphi localization system. Translates resourcestrings and all strings in forms regardless of any 3rd party components used. Works on compiled application. Source code is never used. Generates localized binary resource modules (resource DLLs). Does not use an external compiler. Can import existing translations from compiled application and resource modules or from XLIFF localization source files (dfn, rcn files). Read and save TMX and TBX translation memory files. Import Translation Memory from TMX (Translation Memory eXchange), TBX (TermBase eXchange), Microsoft Glossary and CSV. Machine Translation using Translation Memory, Microsoft Translation Service or Microsoft Terminology Service. Forms, Components, Types and Values that should be ignored can be specified in a Stop List. Translations are Spell Checked. Validation Rules to catch common translation mistakes. Supports Right To Left (RTL) editing based on translation language. Translation project is stored in a single XML file. Command line interface for use in automated build systems. Fast! Refreshing a large project typically takes less than a second vs. many minutes with the ITE/ETM. Supports all Unicode versions of Delphi (i.e. Delphi 9 and later). Resource modules contain the version resource of the source application. What it doesn't do There's one task that BTM, by design, doesn't attempt to solve: Localizing the placement and size of controls. Since it has been my experience that it is a far better idea to design the user interface in such a way that the layout automatically accommodates changes in font- and text size and shorter/longer texts due to translation, I decided from the start that I would not be supporting localization of size and position of controls. This also relieved me of having to create a run time form designer, supporting 3rd party controls visually (something that nobody so far has managed to find a foolproof solution to) and deciding what individual properties constitutes size/position values. Instead I just localize all string values - and only string values. But wait... There's More! Yup, you not only get this little wonder for free. You get the full source code too. Grab it at the repository linked at top. More details at the repository. Enjoy / Anders Melander

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

Good point, but IMHO Skia is just in the early phase of rocketing launch into many projects. I would assume this may stay quite some time very active, the more people get aware of this nice library. Edit: References References References

Really impressive, you seem to revive all-in-one approach of good old Opera!

Unlike fmx Skia is developed by Google. They have more resources and ..... (I cannot write here that unlike Embarcadero most probably they will keep it stable).

Thanks for the insights, this is what I expected too. There was a TScene "demo" from Eugene which pointed maybe in the same direction, this library I checked out some years ago, but never implemented into my current apps yet because the advantage was not so big for me. Maybe that could be more relevant with Skia now, or is this already obsolete technology ? If Skia is able to perform so well and stable, I will give it a try soon, probably beyond just testing. My biggest concern is if such system is resilient and production stable now, or rather might break in the next OS or IDE updates. I see you'r updating very eager, and it seems well supported, so thats a very good sign. FMX is not really stable for me, and tend to behave different in every version. If Skia is an approach to make FMX more stable, I'm jumping on that train very likely, but if Skia is adding another dimension of new failure modes, I will probably will make more tests.

Sorry for the shameless promotion but BriskBard allows you to set any proxy.

No. Any custom graphics just confuse users of business apps. Moreover, it will burden remote channels with no real benefit

What's the sense in such surveys gathered from 20-30 guys?

Well, original FMX canvases are very different depending on the platform. While for Android FMX repaints the whole screen, on Windows FMX only repaints the parts that need to be redrawn. In addition to what Vinicius answered, Skia4Delphi is indeed faster on most platforms, especially Android and has a lot of other advantages. But to answer your question, no, Skia4Delphi renders all controls even if only a small fraction has changed. I myself had the same question, and was thinking that it would be more efficient to only render the parts that have changed, but appraently Vinicius and his brother have done some tests and this was not the case. Implementing "dirty region" repainting within the FMX painting framework is not a trivial task - I have looked into it myself, and have abandoded this project for myself (or postponed at least).