Leaderboard

The FNC components are intended to save you the most EXPENSIVE time -- YOUR PROGRAMMING TIME. If you don't value your time, then don't bother using them. You could also look at the source code and see what they're calling "under the hood" to investigate if there may be a more efficient approach on one platform or another. There may well be. But so what? In order to get a set of components that work and act the same on all platforms, they've needed to implement certain abstractions that are necessarily going to have a cost. That said, the time of the data transfers in this instance will, in most cases, swamp out the abstraction logic, unless they're doing unnecessary data copies. The truth is, most people do not bother to optimize their images in the first place. So you're looking in the wrong place for large speed improvements! Do you have any idea how much bandwidth is wasted by people who take 16 MPixel images then send them to their friends to look at in a 1" x 1" box on their cell phone? A 16 MP image is like a full HD screen in resolution; the 1" x 1" box on the cell phone is under 10kb for an image that most people couldn't see any difference between the two. You need to optimize the images BEFORE they're downloaded to get the most sigificant improvement in DL speeds! Because there's nothing you can do to move an 8MB image as if it's only 10KB in size.

It took me a bit longer than expected to get here but I believe I've finally reached the goal. The following shows VTune profiling a Delphi application, with symbol, line number and source code resolution: Download Get the source here: https://bitbucket.org/anders_melander/map2pdb/ And a precompiled exe here: https://bitbucket.org/anders_melander/map2pdb/downloads/ The source has only been tested with Delphi 10.3 - uses inline vars so it will not compile with older versions. Usage map2pdb - Copyright (c) 2021 Anders Melander Version 2.0 Parses the map file produced by Delphi and writes a PDB file. Usage: map2pdb [options] <map-filename> Options: -v Verbose output -pdb[:<output-filename>] Writes a PDB (default) -yaml[:<output-filename>] Writes an YAML file that can be used with llvm-pdbutil -bind[:<exe-filename>] Patches a Delphi compiled exe file to include a reference to the pdb file -test Works on test data. Ignores the input file Example: Configure your project linker options to output a Detailed map file. Compile the project. Execute map2pdb <map-filename> -bind Profile the application with VTune (or whatever) Known issues The -bind switch must occur after the filename contrary to the usage instructions. PDB files larger than 16Mb are not valid. This is currently by design. 64-bit PE files are not yet supported by the -bind option. As should be evident I decided not to go the DWARF route after all. After using a few days to read the DWARF specification and examine the FPC source I decided that it would be easier to leverage the PDB knowledge I had already acquired. Not that this has been easy. Even though I've been able to use the LLVM PDB implementation and Microsoft's PDB source as a reference LLVM's implementation is incomplete and buggy and the LLVM source is "modern C++" which means that it's close to unreadable in places. Microsoft's source, while written in clean C and guaranteed to be correct, doesn't compile and is poorly commented. Luckily it was nothing a few all-nighters with a disassembler and a hex editor couldn't solve. Enjoy!

Adding a layer of action to achieve a goal is probably not well accepted by long time MMX users as it would break their work flow. Even if such functionality would exist, which class should the method be added when DoIt is not declared in TMyObject, but in TMyBaseObject, which TMyObject is derived from? Instead of asking for the target object each time, it is much simpler to Ctrl-Click on the TMyObject reference or even the DoIt reference in the code, which immediately selects the requested object on which the Add Method action then can be executed on.

I'm working on Ryzen 5900X, the computer after switching from i7 3770 got such wings that I close the windows to keep it from flying away 😉 I work in a virtual machines (vmware), currently I have 2 machines open. The system on the host is Ubuntu, which has very low requirements and low overhead. The ram usage (including the two virtuals) is currently at 10 GB (and I have Firefox open with many tabs, Slack, Telegram and many background services). I strongly recommend AMD

This problem reminds me of a system I had to analyze in college for an Information Analysis course that involved a new meal ticketing system being set up in the cafeterias around campus. They wanted people to be able to buy a meal ticket at any of the cafeterias, right there in line. So Joe would buy a ticket, get it scanned, and go in to have lunch; but his buddy Bob would come by just as he was entering and say "Hey, Joe!" and they'd shake hands and the ticket would invisibly move from Joe to Bob. Then Bob would go to another cafeteria and use it again. They knew there was a problem, and some said it was a bug in the software. But that wasn't it. Joe got what he paid for, but Bob got a free meal. This is a very old and common problem involving a state machine that has nothing to do with Delphi, web apps, firing events, QR codes, or how many gaming centers a company may or may not have. And it's not so much a matter of programming as it is recognizing the nature of the problem and the best approach to a solution. First, I suggest you rewrite the description, leaving out all of the implementation details. They may be causing you confusion. Express it as a list of "current_state -> event -> next_state" rules. Second, refresh your knowledge of protocols and state machines, and review "protocol sequence diagrams" and maybe "state transition diagrams". (There are certainly tools that let you do this, but a pencil and paper are probably much quicker.) Third, go read some of the RFCs for email handling on the internet from back in the 70s and 80s. The internet was literally designed to survive a nuclear attack that took out random data centers, and the data packets (eg, email messages) would still find their way to their destination in a reasonable time-frame. (Results may depend on one's definition of "reasonable".) What you're trying to model here isn't much different than how basic email delivery is managed. Data moving at 150 baud on a dial-up line is pretty damn slow by today's standards; but sending out a 64 byte packet (probably overkill for this) will still make it 10 miles across town way faster than any human can move. Which leads us to the forth and final thing to do: write up the Terms and Conditions that apply to all kinds of tickets and how they can be used in this network. Starting with the misnomer that "customer buys a ticket" equals "days of free [access]". That's like saying if you buy a bus pass for a week then you get a week of "free rides". No! If you don't have that pass with you and you're caught, it's going to be even MORE expensive than what you already paid, right? (This was the source of the problems with the meal ticketing system I analyzed. They were selling tickets at the door, but the data was entered manually some hours later, but before the next meal. So the tickets could be used any number of times between when they were purchased and when they got entered into the system. They had to change the rules about when tickets could be purchased, and ensure the data was entered into the system before they could be used.) Terminology is important when it comes to design. In this case, the system might actually support "free passes". And if a center is stuffed to the gills with customers who PAID for tickets, you might want to BLOCK those with "free passes" from coming in, or just during certain times. See the distinction?

uses System.Net.HttpClient; procedure TMainForm.Button1Click(Sender: TObject); var HttpClient: tHttpClient; m: tMemoryStream; begin m:=tMemoryStream.Create; try HttpClient:=tHttpClient.Create; try HttpClient.Get('https://www.embarcadero.com/images/logos/logo-black-corp-grey.png', m); finally FreeAndNil(HttpClient); end; m.SaveToFile('r:\img.png'); finally FreeAndNil(m); end; end;

Although Vcl.Styles is not mature. I would say it is usable. The Delphi IDE is a proof of that. I have been producing PyScripter with Vcl.Styles for the last five years, and I had no issues that could not be overcome. And now you can have per monitor aware, styled Delphi applications. And since this this discussion started about flicker, there are ways of working around that. The Delphi IDE and PyScripter have minimal flicker. The great thing about Vcl is that applications developed almost 20 years ago, can still work well and look modern, just by recompiling pretty much the same old code. I have mentioned this before, just compare to the Microsoft Desktop application landscape. A new framework is introduced every 3-4 years, mostly incompatible with the others: - Visual Basic with ActiveX controls - C++ with Windows API - WinForms - WPF - Silverlight - Xamarin - UWP - WinUI - MAUI - Project Reunion - etc. Where would you be if you invested in Visual Basic and ActiveX controls for example? Ironically, you can still use ActiveX controls in Delphi if you so wish.