David Heffernan

It's difficult to comment on performance related questions without knowledge of real use cases. Presumably you've measured the various options with realistic data on a range of hardware? What did that tell you?

No, it's conditional, as we have said so many times before

Obviously Emba have trailed the new conditional operator (wish they'd call it this and not ternary, but whatever). But we've heard nothing else. So I was interested in the what's new webinar to see what else there would be. Turns out the reason nothing else has been talked about ahead of time is that there is nothing else. I didn't have high expectations, but they've managed to fall well short of them. Has anyone else seen anything worth talking about?

What problem is this project attempting to solve. Because my impression is that the real issue with performance in Delphi is at the level of the compiler and the quality and the code it generates, which is often pitiful. So I don't really see tweaking library functions as likely to have significant impact for actual programs. It seems unlikely that real world program performance bottleneck is in a Delphi library function. Or am I wrong?

Are you drawing directly to screen DC? Or are you drawing to offscreen bitmap and blitting it? Because what you appear to be drawing is so trivial that I can't see any need at all for things like DirectX, OpenGL, Skia, etc. Not that these aren't all powerful tools. Just that you don't need them. It's not at all clear to me that you've actually diagnosed the problem yet.

Definitely quickly enough. So I use graphics 32 to draw off screen bitmap and blit that. Which is still gdi. But you aren't using gdi to draw lines to a DC. That's how you make it fast. It might even be fast enough to draw to off screen TBitmap and blit that.

This can easily be drawn quickly with gdi. You don't need another library.

submit a report to QP

The tooling in RAD Studio is more than a decade behind the many other IDEs around. It's feeble that we are making excuses for it not being able to do basic refactorings.

Well, no sarcasm and this is true. Because we are a software house developing our own product. Obviously other developers work in different settings.

Why read the source code. You can read the documentation. Why wouldn't you want to be confident your code worked? Fine for throw away hobbyist programs. But for professional development you couldn't survive this way. Anyone in my team that tried this would be spoken to.

I don't "get some source code to work on". It's all our own code and we all follow the house style, obviously.

I mean just never ever ever use single statement, always use compound and it's a non problem.

I corrected it at the time. I wonder what the session management is for this bot.

I was interested in the new AI chatbot that Emba are offering, which was announced in the webinar yesterday. It's at: https://www.embarcadero.com/radaicompanion The concept is that it is an AI bot that has been tweaked to target Emba products, Delphi, C++Builder etc. Anyway, after a recent question on SO I asked: Does the VCL have a TagObject property? The answer was a little disappointing: Yes, the VCL does have a TagObject property. It is available in the FMX.Types.TFmxObject class, which is part of the FireMonkey (FMX) framework, not the VCL. The TagObject property allows you to store any TObject value. I mean it gets there in the second sentence, but starting with Yes is poor. Classic AI people pleaser stuff! I then gave it some more recent SO questions and I have to say it did a good job. I'm quite interested in this concept though, and we've been working on something similar for our product because it's too niche for standard bots to know how to answer tricky questions.

Yeah, some bits and pieces. But I can't see anything exciting. Just a few minor convenience improvements.

95% of this is them saying that they've updated their tools to the latest versions of the various libraries that they are built from, target. Which has to be done, but this is clearly just a maintenance release.

Don't worry, you aren't missing very much!!

There's absolutely no scenario where the performance of these scaling functions could be important. It's just blind asm for the sake of it, premature optimisation 101

Yes, ScaleValue is it.

You definitely don't want to be doing this when the VCL provides exactly this functionality.

Sure you can write a dictionary that works with just these keys. But what is the point of a dictionary that works with these specific five keys? Have you got a real world example to hand?

madExcept is known to have really solid stack trace capabilities so it does seem very likely that it's a mis-configuration rather than any issue with madExcept or Delphi

Given that they never fix bugs in anything other than the very latest release, it's not that big a loss!

You didn't account for any font scaling. So if the user has a high dpi screen and a font scaling larger than 100% the your 26 and 8 won't be right. Then again, because you didn't provide full code and details we are all guessing a bit.