Anders Melander

I found this in my usenet archives about the evaluation order:

The algorithms in that link are okay. It's your implementation of them that's a problem. Just get rid of all the HSL stuff and you should be fine. The formula you call "luminosity" is using the Rec 709 coefficients for "luminance" used in HDTV video. I recommend you read these two sections: https://en.wikipedia.org/wiki/HSL_and_HSV#Lightness https://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages

You haven't shown how you're handling the bitmap returned from ConvertToGrayscale but besides that your exception handling is wrong. Use this pattern instead: begin Source := TBitmap.Create; try Result := TBitmap.Create(...); try ... except Result.Free; Result := nil; end; finally Source.Free; end; end; Apart from that your grayscale algorithm is horribly inefficient (and wrong). Why use HSLToRGB when you know that for grayscale R=G=B and why use RGBToHSL when you already operate directly on the RGB values...?

https://web.archive.org/web/20000620192211/http://www.totalqa.com/products/qtime.asp

I'm pretty sure it was the other way round. AFAIK it's still written in Delphi.

Aren't you using map2pdb with VTune?

It works fine but it's nowhere near as comprehensive as VTune. One advantage is that it works on both AMD and Intel platforms. I have AMD uProf version 3.2.449 installed and that works fine on my system.

And you're looking at the main thread? This is probably the COM apartment threading in play. If so, one of the other threads will most likely be running code in MSXML.

I'm on Windows 7 (on my main dev system) so no 😕 The latest version that works on Windows 7 is VTune Amplifier 2019. I guess I should give it a spin on my laptop (Windows 10 something something) instead before I judge it. That said, the version of msdia140.dll (which is Microsoft's interface to the pdb file) I'm using is the latest one and as far as I can see msdia140.dll is the bottleneck. Of course it might be that my version of VTune isn't using it correctly. I was just considering writing a replacement for msdia140.dll but it would be great if I don't have to go down that rabbit hole.

I dunno. Don't you find VTune's poor performance to be a problem? Personally I either need to be really desperate before I resort to VTune or I must have a very good idea about what I'm looking for (like, I need *this* exact function to be faster but I don't exactly know how to make it so). I have had successes with VTune in cases where I needed to optimize some SSE code but that's about it. On the project I'm working on right now (pure Pascal) it takes VTune over an hour to load the pdb file and so far it hasn't told me anything I didn't already know (from pausing in the debugger).

François, for something like this you probably don't need a profiler at all. Especially not an instrumenting profiler (more on that later). What I always do, before resorting to profilers, is to simply run the code in the IDE and pause the execution in the debugger when the time critical code is executing. Statistics dictate that the current call stack will show you exactly where your hot spot is. Repeat a few times to verify. Basically this is the same approach a sampling profiler uses. The problem with instrumenting profilers is that the overhead of the instrumentation code affect the timing results so much that you can't really rely on it. They're great at determining call graphs and identifying the relative call frequency of different methods, but in my experience you can't use the timing for much.

It's not "clever". If real problems gets too hard to solve just invent some easy ones.

You misspelled Obfuscation.

Very nice. That actually makes it very clear what the problem is - but isn't there something missing? You've declared Child but not actually referenced it anywhere. Maybe you meant to write: Y<T: Child> = class(X<T>) ...

Instead of this: const sCannot: string = #13#10 + 'Cannot send AP Emails!'; do this: const sCannot = #13#10 + 'Cannot send AP Emails!'; and then read: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Declared_Constants#Typed_Constants As I read the documentation, if you make the const typed then the compiler cannot concatenate the strings at compile time but will have to do it at run time. Probably because typed consts can be modified at runtime if you have that option enabled. In your example it's a variable local to the method. I'm sure there are also still people who argue that it's safe to run with scissors as long as <insert excuse here>. No seriously, stop using "with". It doesn't make you code more readable. On the contrary. It's impossible for someone else (i.e. that unfortunate person who will maintain the code after the author has moved on to greener pastures) to see if an identifier references a "with'ed" member or something higher up in the scope. Also the debug inspector can't cope with it. You might think that in your case it's safe because <insert excuse here> but I could identify several things that could go wrong in your code that you apparently haven't thought of.

Not related to your specific question but... Get rid of that. TaskMessageDlg already plays the system sound associated with the message type. Does sCannot really need to be a typed const? As far as I remember it's better type use untyped string consts since these will end up in R/O memory. Also you use #13#10 here but sCRLF everywhere else. Personally I prefer #13#10 (or just #13 when that is appropriate) since it's more explicit. Since MailSender is a local var and only used inside the try...except block, there's no point in using FreeAndNil() here. Just use Free instead. If you only use FreeAndNil when there's a reason to then it will communicate to the reader that here's something to be aware of; The var needs to be nil when it doesn't reference a valid instance. Since you're already refactoring all this, get rid of the "with" statements - and forget you ever learned about it.

Not that what you say aren't true, but look at the screenshots. It's Delphi 7 so strings are basically byte arrays.

To my knowledge there aren't any (better, that is).

Sure. I agree on that. It is something to consider though. In this case we are reliant on explicit support for newer versions of Delphi since this is an IDE integration-only tool and the parser also needs to be updated when the language changes. So far there has not been problems but I do worry a bit. As I said I use it myself and it does what it's supposed to do rather well but the output is beginning to look a bit dated (VS2012 style), the help is out of date (or completely missing as in the case of the latest release) and the advertised new versions has never appeared.

Yes, very useful. I use it on a number of projects myself. I'm a bit hesitant to recommend it though as: It seems to have gone into maintenance mode many years ago. It appears to rely on MSHTML for the editor feature and MSHTML is a dead end.

If you only want to convert from PNG to BMP then just assign the TPNGImage to the TBitmap. If you want a bitmap containing two PNGs side by side (or one on top of the other), then create a TBitmap of the desired size and then draw the PNGs onto the bitmap canvas at the desired locations. Uwe's examples contains most of the necessary code. You can't. CopyRect requires a TCanvas and TPNGImage ain't got it. TCanvas is a wrapper around a GDI device handle (HDC).

That didn't answer my question: Why should they? "There's little cost" isn't a reason because there's even less cost in not doing it. IMO nobody will benefit from browsers supporting this format (apart from the authors ego 🙂 ).

Why should they? I mean, what's the benefit? It compresses worse than PNG and WebP and only supports 32-bit RGB(A). I agree that "it's pretty" but that's irrelevant when they already have the other formats implemented. It's even irrelevant if they hadn't.

Phosphoglucose Isomerase ? https://www.abbreviationfinder.org/acronyms/pgi.html

Meh. As far as I can see it just does RLE and Delta compression so it's no wonder it's faster. It's also no wonder that it doesn't compress as good as PNG (look at the benchmark numbers). Also it only handles 32 bit RGBA image data. I guess it's fine for internal application use but it's definitely not a general purpose image format.