Anders Melander

I've just merged it and as far as I can see that's your first PR to the graphics32 repository, so I guess you meant that you got ignored at some other repository? It seems graphics32 is de facto without a project lead and I appear to be the only one of the old core team doing anything with it these days so there's not much progress or direction anymore. The fabled 2.0 release was planned almost 10 years ago but these days no one seems interested in making it happen and moving forward.

I use Plastic's regular 3-way merge tool with Git but I've never used Plastic SCM itself. You can get your hands on the merge tool by installing a trial of the Plastic SCM client. I don't think Semantic Merge has working support for Delphi syntax. There are some external parsers but AFAIK they don't support the newer versions of neither the Delphi language nor Semantic Merge. Here's one: https://github.com/andremussche/SemanticMergeDelphi

I've attached an old library (from 1999) that can do it for you. I believe it's been incorporated in several other libraries over the years. I haven't used it since D5 so you might need to tweak it a bit for newer versions. Apart from that I would probably use Graphics32. resample.pas

I worked as the lead developer for seven years at a company that pretty much made it their business to move people from Excel to "something better". https://sigmaestimates.com/

You test is a synthetic benchmark of metrics you don't understand yeilding results you don't know how to interpret. As usual this is completely pointless. I see you've highlighted the peak working set size but do you even know and understand what a working set is? If you really want to learn about how different memory management challenges can affect you then start by learning about what those problems are. Make an effort. One of the reason why your benchmark isn't doing as bad as you'd expect is probable the lack of randomness in the test. You're repeating the same pattern 100 times. If your allocation were random this would fragment the heap badly but since you're allocating, freeing and then later reallocating the same block sizes again and again, there's good likelihood that the blocks can be reused.

Yes but the topic isn't "stuff that scale nicely".

Not really relevant to the topic.

A psychoanalyst would have an opinion or two about that statement. I'd say you've integrated your weirdness nicely That's a pretty unnuanced statement. I'd say it has a more narrow meaning than what most people think, The rest of your post made little sense to me. Regarding IQ and "intelligence" I would recommend this book: https://www.amazon.com/Intelligence-Reframed-Howard-Gardner/dp/0465026117 or any of his other books on Multiple Intelligences.

Googling "delphi natural sort" would have gotten you the answer.

I don't have any knowledge about your exact problem but: You have the source so you should be able to see how and why assigning a popup menu to the control affects the standard menu. Use a TActionList instead of wiring the menu items directly.

If it works for you then that's great. Why should I try to convince you otherwise.

Yes, exactly like that. Now you just need to convince Embarcadero to integrate it with the IDE. I haven't tried it yet as I wasn't too happy about adding one problem (an external dependency) to fix another one. I'll give it a try now anyway. I guess that should be fixed by the authors. Did you try to make that happen?

Indeed. All paths relative and everything it source control. This also makes it trivial to build the project on a build server. At my current client the main product used to have dependencies on 5-6 different Git repositories and a bunch of 3rd party libraries that wasn't under source control. One person was responsible for figuring out what revision to checkout from the different repositories and what version of the 3rd party libraries to install and then build a version that could be sent to QA or deployed to the customers. And of course there were no relative paths. It was a nightmare. I moved everything into Git, made the dependent repositories submodules of the project repository, adding the source of the 3rd party libraries (also as submodules) and made all the paths relative. It took a few days to set up and now we have a fresh build after each commit. Wouldn't it be great if the project package configuration actually worked like most people expect it to (i.e. only load the packages specified in the project settings) and we could specify a (relative) path to the packages? I wouldn't even mind if I had to restart Delphi to switch from one project to the next. It would be better than the current situation.

Yes but by doing it explicitly, at the point of your choice, you control exactly when it happens. The autocreate form/datamodule code, using TApplication.CreateForm, is managed by the IDE and it has been known to mess that up once you start editing the dpr file.

That was pretty much the point of what I wrote; You can't just rescale an image (vector or raster) at run time and expect good results.

The problem is the same as the one you have when you resample bitmaps. For small bitmaps you want to leave out a lot of details but keep the important parts and take advantage of the fact that the brain uses pattern recognition to reassemble the details. For larger bitmaps you can add details but leave of parts that were necessary in the smaller bitmaps for pattern recognition. This is why one can't just start with a large bitmap and downsample it to whatever size needed. The result usually looks awful. Same with SVG: For small SVG you don't necessarily want all the vectors to be rasterized. For larger ones maybe you do. An example of this is TrueType font hinting; Rasterizations of a font to a small point size uses different metrics and rules than the rasterization of the same font to a larger point size. One reason is that even with antialiasing we still need to take the pixel grid into account to get a good result.

You believe it may? If you want vectorized images that sometimes, maybe, almost, resembles the original bitmaps, then yes I'm sure you could train an engine to do that. But it would be faster and cheaper to just have a professional design a new set of vector images.

You don't convert your PNGs to SVG. You have to replace the PNGs with new SVG images. Since SVG is a vector format (hence the "V" in SVG) the visual expression will probably be very different from what you have now and it might not be what you want. There are probably someone that will suggest using vectorization to convert from PNG to SVG but I wouldn't bother. Vectorization only works well with large bitmaps. If you stay with raster images then you have to provide the individual bitmaps in different sizes and use something like TVirtualImageList. You typically don't need that many different sizes; 16, 24 and 32 should do but that of course depends on what amount of scaling you're willing to accept. Make sure that your bitmaps use alpha for best result - i.e. PNG or 32 bit bitmaps.

Compile and press F7 and you'd know. I would recommend that you change the autocreate datamodules so they're created on-demand instead. That way you'll defer the overhead until the datamodule is actually needed. Something like: type TMyBigDataModule = class(TDataModule) ... end; function MyBigDataModule: TMyBigDataModule; implementation var FMyBigDataModule: TMyBigDataModule; function MyBigDataModule: TMyBigDataModule; begin if (FMyBigDataModule = nil) then FMyBigDataModule := TMyBigDataModule.Create(Application); Result := FMyBigDataModule; end; Yeah. All those features and versatility definitely comes at a price. Since they switched to a subscription only model they have become become lazy with regard to avoiding dependencies and so the applications become pretty bloated. Put a simple grid on a form and you get much of the spreadsheet stuff linked in as well.

...at least one too many

So the problem isn't actually related to "How to optimize exe loading times" but rather "how to speed up form loading"...? I use the layout control a lot, and on complex forms it can become a bit slow, but I've never had it affect application startup time or the time it takes for the main form to display. You aren't by chance "auto creating" your forms?

That's not what Assert is for. An Assert is a verification that the assumption under which the code is written holds. If the assumption proves to be wrong, i.e. the Assert fails, then all bets are off. There is no "best effort" that can save it. There's nothing to prevent the application from presenting an assertion error the same way as all other exceptions, but the fact is that it's an internal error that the user can do nothing about, and the application shouldn't just pretend that everything is fine. Since I write a lot of framework and library code I use assertions a lot but at one of my former employers, a company in the medical device sector, I was told to remove all assertions because it "made their software look bad". Pointing out that that if there was assertion errors then looking bad was the least of their problems didn't go down well. Apparently they preferred random catastrophic errors of unknown origin to immediate errors that could be traced back to their software.

Do you prefer Access Violations or other random errors?

It's a QPAD MK-80 so not a RGB keyboard; It's blue or nothing. It's using Cherry MX Blue switches (tactile+click - the closest I could come to the IBM model M) and AFAIR it wasn't possible to get RGB with those switches back when I bought it.

Well my alternate keyboard, the one I use when I'm traveling or need USB connection (the IBM keyboard only has the old PS/2 connector and draws too much power to boot reliably from USB ) has blue illumination with variable intensity. Blue is pretty but I'd much prefer red as it's easier on the eyes when it's dark. Yeah, I can think of some applications too but then the user isn't really supposed to be looking at the keyboard so I think I'll file that idea under "sounds like a good idea, but..."