Steve Maughan

Thanks David — this is what is feared. I had hoped it would act like a PNG with transparency at the pixel level. Cheers, Steve

Hi Vandrovnik — I'm aware of the basics of Difect2D, but how could I merge two Direct2D canvases and preserve the anti-aliasing of the text? If I'm not mistaken this isn't easy using Direct2D (but I'm far from being an expert on this). Thanks again, Steve

Interesting — how would you accomplish what I'd like to do using Direct2D? Thanks, Steve

My mapping program is a VCL app that makes extensive use of GDI drawing to draw the map. I've recently upgraded from Delphi 10.2.3 to 10.3.2. The version compiled with Rio will often lock up after being used for 20 minutes. The app becomes unresponsive for about 15 seconds. In that time the CPU utilization is close to zero and the memory usage doesn't change. After the lock-up it will sometimes become fully responsive or in some case will only be responsive for a moment. There are no error message during or after a lockup. The application is compiled as 64 bit and uses about 1.6 Gb of memory while the test machine has 32 Gb i.e. it's not short of memory. What could cause the lockup? My first thoughts is it's something to do with GDI. Has anything changed with GDI in Delphi Rio compared to Delphi Tokyo? Or maybe it's a virus scanner. I use Panda Dome. I'll switch it for something else to see if that's the problem. Or could it be Windows 10 messing with the memory allocation? I've just updated to Windows 1909. I know it's a long shot but any suggestions are welcome. Steve

I finally got to the bottom of this error. It's a bug in the Parallel Programming Library that ships with 10.3.2 and 10.3.3. Here's what happened... After I downgraded to 10.2.3 I was just pleased that the freezing stopped. I was also concerned that I'd be stuck using 10.2.3 for ever. So this week I upgraded again; this time to 10.3.3 in the hope the bug didn't show up in this version (the bug had initially appeared in 10.3.2). Unfortunately it showed up—I was gutted! I tried replacing the memory manager - that didn't work. I tried checking for resource leaks; there weren't any. I then switched the main rendering routine to use OmniThread instead of the PPL and that corrected the bug. It seems that after being under load, and then left for a while, the PPL's can suspend some threads for a period of up to 1 minute. If the suspended thread is in a "for" loop the program freezes. Eventually the application comes back to life but it happens repeatedly. The bug wasn't present in 10.2.3 but was present in 10.3.2. I'm elated that the bug is gone! Steve

I have quite a large list of 3000 objects stored in a TList<T>. I need to delete about half of them in a time-critical manner i.e. as fast as possible. I don't need to free the objects, just delete them from the list. Two possible approaches come to mind. I could simply iterate through the list and repeatedly call List.Delete(index) for each item I'd like to remove. Another alternative would be to set the item to nil and then call List.Pack at the end. Is there any advantage in the second approach? Any other insights appreciated. Steve

Hi Stefan - is it? I can't see why it would be a bad idea. Any links to enlighten me? Steve

Yes - I'm a total sucker for it.

In truth, little. It's just part of an optimization algorithm that needs to be as fast as possible.

Hi Kas - that's a good idea!

HI David, Anders & Attila, Thanks for the input - I really appreciate it. I've recompiled with Tokyo 10.2.3 and the problem seems to have gone. I'll need to investigate further. I have madExcept so I'll see if that helps first. Thanks again, Steve

Hi Anders, I took your advice. There was nothing on the call stack, even in debug mode: Interestingly, after the freeze I started Loom and SnagIt to record the video. Both wouldn't start until AlignMix was unfrozen. To me this implies it's something to do with Windows 10. Thanks, Steve

Here's a video showing the behavior: https://www.loom.com/share/8a00020c3ba440df9a8998dbe17dc1f0 Any suggestions greatly appreciated. Thanks, Steve

My application manages sales territory alignments e.g. zip code "32779" is assigned to territory "T164". Typically many people want to access and make changes to these assignments. For example, the manager on the west coast may want to dissolve a territory, and a manager on the east coast may want to expand a territory. It seems to me this is akin to version control. This being the case I've been thinking that Git could be used to manage the alignment version control. For this to happen I'd need my application to be able to access all the functionality of Git: commit, pull etc. Has anyone done this before? Are there any Delphi Git components or tutorials? Would I need to distribute a copy of git - I assume I will? Steve

David & Thomas - you may well be right; it may be too complex for clients. Thanks, Steve

What's your thinking? Potentially a company will want distributed people working on their part of the alignment. They may experiment locally themselves with different alignments before committing to the main alignment. They'd also like to be able to rollback changes to see what the alignment looked like at a specific date. To me this seems akin to software development. What am I missing that a central database would provide? Thanks - Steve

Since the new MacOS compiler is based on LLVM I'd be interested to see any executable speed comparisons against Delphi Win 64 compiles. Won't the LLVM based compiler produce executables that run significantly faster? Or am I being too optimistic? Steve

Back when Rio was initially launched I remember Marco mentioning it now supports Windows Pen / Ink. This would enable apps to use the Surface Pen. I can't find anything in the documentation. Does anyone know of a demo of how to use the Surface Pen with Delphi 10.3? Thanks, Steve

Hi Gunther, Thanks - I'll take a look. This solution seems to use an ActiveX control. I was hoping to access via WinRT. Cheers, Steve

No LLVM optimization is really disappointing. If you wind the clock back to 1995, many of the early developers coming from VB3 were exited about a compiled executable that ran at the same speed as "C" programs. They wanted and valued fast executables. Borland / Codegear / Embarcadero have each ignored this value their developers place on fast code and haven't improved the code optimization for 20 years. It seems they take a, "it's good enough" view. I'd encourage them to invest some time and include all the optimizations that LLVM offers (even if it slows down compilation speed for the Release Build). I think they'd be surprised at how well this would be received by the Delphi community. Steve

Is the new release (10.3.2) component compatible with 10.3.1? I'm seeing some component vendors (e.g. DevExpress) say their latest release supports 10.3 (i.e. no mention of the ".1" or ".2"). This implies it will install components into 10.3.1 and 10.3.2. even thought this version of their components was released before 10.3.2 Can anyone confirm? Thanks - Steve

Have they done that? Why would they do that? Thanks, Steve

Ugh!!! Thanks for sharing

Hi David, I'm certainly not an expert in this field. Over the years I've seen various speed benchmarks that suggest Delphi's Windows compiler produces executables that are significantly slower than those produced by the top C++ compilers (e.g. Intel). In the chess world (where I am an expert) the rule of thumb is a Delphi version of a chess engine will run about 30% slower than the C++ equivalent code bases (Critter is the engine that was developed in two parallel code bases). Let's face it, there doesn't seem to have been any work done on optimizing the code created by the Delphi compiler in the last 20 years. I'm just hoping the new backend will be better. Thanks, Steve

Apparently the new macOS Delphi compiler is based on the LLVM compiler. I wonder if future Delphi compilers for Win32 / Win64 will also be build on top of LLVM? Would this improve the speed of the final executables? Steve