Anders Melander

That's correct. A fully transparent pixel has no color. I'm not sure what it is you're showing here. I contributed code to handle that in 2011. See TKernelResampler.GetSampleFloat. That said there does seem to be a problem because when I resample in my own bitmap editor the alpha isn't handled correctly. I'll look into it.

Of course it's wanted. Improvements are always welcome and you seem to have a really good understanding of the subject. You might opt to have two versions instead: One for 32-bit opaque RGB and one for 32-bit RGBA. The premultiply/unpremultiply really messes with the quality since you're operating on 8-bit values. One way to avoid this is to premultiply to floating or fixed point, resample the floating/fixed point values and then unpremultiply back to 8-bit. As you can imagine this doesn't exactly improve the performance or memory usage. The memory usage can be lessened by processing one channel at a time.

Very nice. As a Graphics32 contributor I would have preferred though that you'd spent the (probably considerable) effort improving Graphics32 🙂 A few suggestions: Use TStopWatch to measure elapsed time and add the stopwatch as a parameters to TScaleProcedure. This way the procedure can pause the stopwatch when it's doing something which shouldn't be included in the benchmarking. For example assigning back and forth between TBitmap/TBitmap32. Use TTask instead of TThread. This solves your problem of how to manage the threads and avoids the overhead of creating the threads. I understood that you had problems with TTask, but IMO the solution to that is to locate and fix those problems rather than avoiding TTask. For Graphics32, using the memory backend instead of the GDI backend is better when you don't need to use GDI features. See below. In this case it doesn't make much of a difference though. Your code seems to handle RGBA but as far as I can tell you're doing it wrong. You cannot process each RGBA channel independently. Instead you need to operate on premultiplied RGBA values. For example you wouldn't want an RGBA value of $00FFFFFF to have any influence on neighboring pixels. So: 1) Premultiply, 2) Resample, 3) Unpremultiply. Unfortunately this will probably have a very negative impact on both performance and quality. Have cake/Eat cake - Choose one. FWIW, Graphics32 does have a multi-threaded rasterizer but since it uses TThread it doesn't make sense to use it in your benchmark since the overhead of thread setup/teardown for just a single call would kill performance. procedure LanczosGR32(const Source, Target: TBitmap; parallel: boolean); var Source32, Target32: TBitmap32; Resampler: TKernelResampler; begin Source32 := TBitmap32.Create(TMemoryBackend); Target32 := TBitmap32.Create(TMemoryBackend); try Source32.Assign(Source); Target32.SetSize(Target.Width, Target.Height); Resampler := TKernelResampler.Create; try Resampler.KernelClassName := 'TLanczosKernel'; Resampler.Resample(Target32, Target32.BoundsRect, Target32.BoundsRect, Source32, Source32.BoundsRect, dmOpaque, nil); finally Resampler.Free; end; Target.Assign(Target32); finally Source32.Free; Target32.Free; end; end;

Hey, that's cheating 🙂

Google "OposBiometric activex", 3rd result: http://carol.havocshack.com/carol-winslow-tech-writer/files/one-touch-for-windows-sdk-com-activex-developer-guide.pdf

From: https://www.openwall.com/lists/oss-security/2022/03/28/1 via https://github.com/madler/zlib/issues/605#issuecomment-1084218467 The following are the only (two) calls to DeflateInit2 in the Delphi source (System.ZLib.pas): procedure ZCompress2(const inBuffer: TBytes; out outBuffer: TBytes); ... begin ... ZCompressCheck(DeflateInit2(zstream, 1, 8, -15, 9, 0)); ... constructor TZCompressionStream.Create(dest: TStream; compressionLevel: TZCompressionLevel; windowBits: Integer); begin ... ZCompressCheck(DeflateInit2(FZStream, ZLevels[compressionLevel], Z_DEFLATED, windowBits, 8, Z_DEFAULT_STRATEGY)); end; Note that one uses MemLevel=9 and the other MemLevel=8. None uses the Z_FIXED method the original bug was about.

As far as I've been able to evaluate this bug isn't much of a problem for Delphi desktop applications. Server applications could have a problem if they do compression of user supplied data (the bug only exists in the zlib compressor) but since it's only a buffer overrun (as far as I can tell) it's not that bad.

Okay then. I thought that maybe you were just voicing an uninformed opinion. My bad.

That would mean Windows 8.x isn't supported either: https://sockettools.com/kb/windows-and-supported-tls-versions/

Are there any particular security update, unavailable for Windows 7, that you can't do without?

Looks like a corrupt installation to me, but it's hard to conclude anything from the info available.

Calm down, dude.

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

Ah, I didn't realize who you represented. I'll let you figure it out for yourself then 🙂

Are you patching the compiled binaries or are you generating resource modules for use with the RTL's built-in localization system?

John weeps 😢

That shouldn't matter. Regardless of the dimensions of the jpeg image, it (or rather the internal TBitmap representing the decoded image) will be stretched to fit the target rect. procedure TJPEGImage.Draw(ACanvas: TCanvas; const Rect: TRect); begin ACanvas.StretchDraw(Rect, Bitmap); end;

Weird indeed. Can you tell if it's the TImage itself or only the content which isn't being scaled?

That's pretty useless - "OT" or not. He's using a TImage.

I'm guessing the IDE build is using an internal unit cache when it's building. Try comparing an external build through msbuild with an IDE build where the project is configured to use msbuild (Project->Options->Building->Delphi Compiler->Use MSbuild...)

Doesn't the trial come with full source... Asking for a friend 🙂

Okay, if that doesn't resolve the problem I suggest you try using SysInternal's ProcMon to determine what's going on. Filter on bds.exe and enable the trace just before you do a [Ctrl]+[Enter].

Check if $(BDS)\source\data\firedac is in your browsing path: Tools->Options->Language->Delphi->Library->Browsing path. Does the folder exist on disk? If you [Ctrl]+[Enter] on a FireDAC unit in the uses, does that open the file?

I meant from their perspective.

I don't think it was the environment that turned the forums poisonous. I think it was the almost complete refusal to acknowledge the many problems which alienated a lot of former champions of Delphi (myself included) and made them feel betrayed. Disgruntled fans are often very vocal in their criticism. Anyway, water under the bridge.