Anders Melander

Different layers. I haven't used either but AFAIK RTC Portal is a layer on top of RTC SDK. Note though that it's a completely proprietary protocol. You need something that implements the RFB protocol (which is what VNC uses).

I think you mean this one: https://github.com/CloudDelphi/RTC-Portal-VCL But that is neither VNC nor RDP, which is what the OP asked for. For RDP there is an ActiveX but I don't know what it does. I've never used it. https://learn.microsoft.com/en-us/windows/win32/termserv/remote-desktop-activex-control

GR32 too. No problem AFAIK.

No; I think our scorn for this design choice will be limitless 🙂 https://en.wikipedia.org/wiki/Trie And store the data in a resource.

Here's a quick update on the two issues @Allen@Grijjy encountered: The problem with the overlapping segments has been worked around in code by ignoring conflicts caused by the .tls segment. Incidentally, Allen found an old QC report about a similar issue (RSP-12824). Unfortunately, that issue was closed by someone who apparently doesn't understand what the map file segment offset values signify. Regardless, an overlapping .tls segment now only produces a warning message. The filter problem turned out to be a copy/paste problem. Allen had copied his map2pdb parameter list from a post here, and somewhere along the way, two invisible zero-width no-break space characters (#$F0FF) got inserted into the string he pasted. So what looked like '-include:0001' was actually '-include:000'#$F0FF#$F0FF'1'. I've been bitten by that one myself a few times when I've copied code from a browser.

The syntax is correct. I fixed the Range Check Error yesterday. Pull the latest source. There's no point in having a PDB without line information and, given the parameters you use, you should get a usable PDB. You can mail the map file to anders🍥melander.dk Actually, apart from the .tls problem, they look fine to me. You have to take into account that the PE Tools segment offsets are relative to the image base (see the Optional Header dialog) while the map file offsets are absolute assuming an image base of $00400000.

Yes. This is the exact default setup that I use. I have an additional two setups; One that includes everything (without the -include filter) and one that excludes a bunch of units (-exclude:dx*;cx*;winapi.*;vcl.*;data.*;firedac.*;soap.*;web.*;datasnap.*;id*;vcltee.*) to keep the size of the pdb down. On a related note, I've been considering making a GUI for this so that the filters can be specified visually (I believe AQTime does this). Often you know exactly what part of the code you want to profile and having PDB info generated for the rest is just overhead. No, that's not necessary. By default, everything is included. It's only when you specify an inclusion filter that everything by default becomes excluded. Yes, of course it is. We really need more awareness among Delphi developers of the tools available to them. That was my initial way of dealing with overlaps but the problem with that is that you don't know if the segment you're skipping is the "correct" one. And you might need the segment later on if there are references to it elsewhere in the map file. So far I don't have enough test cases of map files with these overlapping segments to be able to make a decision on how best to handle them, so if I could get my hand on the one you have that would be great. Also, if you could examine the corresponding exe file (I recommend using PE Tools) to find out what the actual segment offsets and sizes are (because they're obviously not what the map file states) that would be a big help. The .tls segment does seem to be a common factor among the various segment-related problems. For example: Again, I could just ignore segments with Offset=0 but then I would get errors later on as there are symbols referencing it. Another solution would be to hardcode handling of the .tls segment but I would really like to avoid a fragile workaround like that and keep the handling generic. Right now I'm mostly leaning toward marking segments causing overlap, or with offset=0, as invalid and then simply ignore all later references to them. The best would of course be if Embarcadero fixed the map file but I'm not holding my breath for that, and I still need to be able to handle what's already out there.

They are not errors. The "debug" prefix tells you that they are diagnostic messages produced because you specified the -debug switch. I have no idea. I guess there's probably something on the VTune site or maybe some help installed with VTune. -include and -exclude are filters that are applied after the map file has been parsed. If neither is specified, everything is included. If -include is specified, everything that doesn't satisfy the include filter is ignored. If -exclude is specified, everything that does satisfies the exclude filter is ignored. -include:* does nothing since it just includes everything - which is the default. Well, overlapping segments should never occur so that would be a bug in Delphi if you have that in the map file. In the first version of your your other message, you stated that you encountered some exceptions but were able to work around them by modifying the source. I'll of course be interested to know exactly what the problem was and what you changed, so I can get it merged into the source if there really is a problem. I'll probably also need to see the map files to get to the bottom of this. You can either create a (public) issue at Bitbucket or PM them to me here.

Okay, but why? Oh, I think I see what you are doing. Is it correct that... ...gives you the smallest size of a kernel containing all values >= 1/255?

Okay, but why? As you know, my calculation is based on FWHM: and the value you use now is the same as Gimp's but I don't understand the rationale for that calculation. Of course, one can use any radius/sigma factor one chooses since it's kind of an abstract value (for some algorithms) but it makes it a bit difficult to compare blurs if they don't use the same scale. The Gaussian RMS test isn't that important, BTW. AFAIR, it does a blur of a single-pixel vertical line and then compares the horizontal pixel values to the ideal Gaussian curve. If your Sigma/Radius differs from the one I use for the test curve it will show in the RMS. For example, a single pass box filter will have a high RMS. Two passes will produce a lower RMS, and three passes even lower, etc., as the filter approximates closer and closer to the Gaussian. The more important test is the Gaussian signal loss. In that, I sum the blurred pixel values and compare that against the summed Gaussian values. I.e. I compare the integral of the filter and the integral of the ideal curve. In theory, they should both equal 255. In practice, rounding errors make this difficult to test precisely. For example, the sum of the ideal curve is 252 for a radius of 10. Your algorithm has a loss of zero against the theoretical ideal curve (i.e. you have a sum of 255). This test should not be affected by the Sigma/Radius value. FWIW: https://brainder.org/2011/08/20/gaussian-kernels-convert-fwhm-to-sigma/ https://mathworld.wolfram.com/FullWidthatHalfMaximum.html

Don't do that; I don't know your code but I would think that very few strings actually need to be AnsiString. And even if your code already supports Unicode there can still be places that assume that SizeOf(Char)=SizeOf(Byte) and SizeOf(PChar^)=SizeOf(PByte^). Also, WideString is not the same as UnicodeString. WideString should generally only be used with COM. https://docwiki.embarcadero.com/RADStudio/Sydney/en/String_Types_(Delphi)

And so will the users if he just ships it 🙂 But seriously; There's already lots of good advice here. If I should add anything it would be to make sure that you do all this under version control (re: Git). That relieves some of the pressure of changing something that works into something that might potentially be full of bugs. It also makes it easy to see what you've changed so far.

Yes, I know you don't need an extra license. My point was that I don't think you even need to run the installer.

You'll be using the command line compiler so you can use any account you like; The compiler is just a regular console application. And as far as I remember you don't even need a license. Just copy the files from an existing installation.

You missed the point: The +$0001 is not necessary. The first available custom message ID is WM_USER, not WM_USER+1.

Then it was a bad example. No, my guess is that it's cargo cult; The +1 is so widespread that most people think that it's the first available value (which it isn't).

One of my current clients has been using ChilKat for FTP & SFTP for years and it seems to work fine. The first thing I did in order to work with it was write a set of wrapper classes that hide the ugly DLL API and abstract the FTP and SFTP differences away. I'd have preferred something with source code though, but AFAIK there's nothing for Delphi and the choice had already been made.

What's wrong with WM_USER + 0 ?

Pretty nice validation result. Extrapolating from your benchmark result, I'm guessing your CPU is about twice as fast as mine and that my blur would process something like 20,000,000 pix/sec on your system. Can that be right? There's no guarantee that my validation algorithm is correct (I cooked it up myself). You might want to verify that before you start mangling your code.

The last time I looked, the JCL JDBG functions didn't directly surface the debug data; You can ask the functions to resolve addresses and so on, but you can't get a list of all units, symbols, line numbers, etc. Isn't it correct that you had to modify the JCL source in order to get the JDBG data you needed out of it for your profiler?

A box blur is almost always faster. Almost...

Source or it didn't happen 🙂

You really do need to handle the alpha channel if you are going to operate on 32-bit bitmaps. Basically, it's the same as what you did for the resampler: Premultiply, blur, unpremultiply. Enable the checkerboard pattern in TImgView32.Background and you should be able to see it. Sure, that would be nice; Go ahead. Just make a version that has the same API as the existing ones: procedure Blur(Bitmap32: TBitmap32; Radius: TFloat); overload; and optionally: procedure Blur(Bitmap32: TBitmap32; Radius: TFloat; const Bounds: TRect); overload; procedure Blur(Bitmap32: TBitmap32; Radius: TFloat; const BlurRegion: TArrayOfFloatPoint); overload; If you start by posting to your own repository I can do the work required to get it integrated into Graphics32. My test bench validates the following: Edge handling Does the "outside" of the bitmap bleed into the blurred bitmap. Basically, I just blur a white bitmap and verify that all pixels are still white. Alpha bleed Does the color of fully transparent pixels bleed into semi-tranparent pixels. Color overflow No R, G, or B values should increase. A minor decrease, when blurring a solid color bitmap, is allowed. Loss/gain due to premultiplication I test the average color loss of blur of a solid color bitmap, with varying alpha. This mostly tests the precision of the premultiplication. Average RGB error and lightness change I blur a gradient and compare the average RGB-, and lightness change. Horizontal and vertical symmetry I blur some horizon and vertical lines and verify that they have been blurred symmetrically. Gaussian error I blur a line and verify that the blurred result corresponds to the Gaussian curve. RMS error and signal loss are validated. Vertical error I blur a vertical line and verify that all rows contain the same color value. Horizontal error I blur a horizontal line and verify that all columns contain the same color value. Uniform RGB I blur a sequence of solid color bitmaps, with increasing R=G=B and verify that the result doesn't contain noise. This usually catches simple over/underflows. The result looks like this: FastBlur (box), Angus Johnson [1024 x 1024, 10] PASS: Edge handling PASS: 100% alpha bleed: 0.00% bleed, 0 errors PASS: Overflows: 0, max swell: 0.00%, 0 bleeds PASS: Alpha: 31, Average loss, RGB: 0.92 %, A: 0.00% PASS: Alpha: 63, Average loss, RGB: 0.52 %, A: 0.00% PASS: Alpha: 95, Average loss, RGB: 0.26 %, A: 0.00% PASS: Alpha: 127, Average loss, RGB: 0.26 %, A: 0.00% PASS: Alpha: 159, Average loss, RGB: 0.13 %, A: 0.00% PASS: Alpha: 191, Average loss, RGB: 0.00 %, A: 0.00% PASS: Alpha: 223, Average loss, RGB: 0.00 %, A: 0.00% PASS: Alpha: 255, Average loss, RGB: 0.00 %, A: 0.00% PASS: Average RGB error: 0.48 % : Lightness change: -0.50 % PASS: Horizontal symmetry error: 0.00 PASS: Vertical symmetry error: 0.00 PASS: Gaussian RMS error: 7.94 FAIL: Gaussian signal loss: 6.67 % PASS: Vertical errors: 0 PASS: Horizontal errors: 0 PASS: Uniform RGB[ 31] errors: 0 ( 0.00 %), noise: 0 PASS: Uniform RGB[ 63] errors: 0 ( 0.00 %), noise: 0 PASS: Uniform RGB[ 95] errors: 0 ( 0.00 %), noise: 0 PASS: Uniform RGB[127] errors: 0 ( 0.00 %), noise: 0 PASS: Uniform RGB[159] errors: 0 ( 0.00 %), noise: 0 PASS: Uniform RGB[191] errors: 0 ( 0.00 %), noise: 0 PASS: Uniform RGB[223] errors: 0 ( 0.00 %), noise: 0 PASS: Uniform RGB[255] errors: 0 ( 0.00 %), noise: 0 In your mailbox in a few days, if you're lucky I'll include the test bench too. By the way, I can really recommend that you profile your implementation with VTune. This is an area that usually benefits greatly from that.

THeY fouND tHe cOdE On ThE InTeRwebS. It muST be ThE beSTESt!