Anders Melander

Yes, there will of course always be some parts that can be parallelized but the problem is that the expensive part, the Huffman decoding, cannot. I'm guessing they used "cooked" jpegs because there's really not much magic that can be done here. I think the effort is better spent on using SSE, AVX, or the GPU to decode - which is also what I believe most high-performance decoders do.

Most modern jpegs require sequential decompression due to the compression algorithms used (decompression of a block is based on the result of the previous block); There's nothing much to parallelize. Jpegs with lots of restart markers (a restart marker means that the result of the previous blocks isn't needed) in the compression stream would benefit from parallelization but it is my understanding that those have become very rare as the problem they were meant to solve (data corruption during download via modem) no longer exist.

Yes, unfortunately.

I think the IDE form designer might work around that; Only one design form can be visible at a time. Just a guess.

The address space of a 32-bit application is 4GB. Some of that is reserved by Windows. By default 2GB but for Large Address Aware applications (such as the Delphi IDE) it's 1 GB. These values can be customized globally. Your hardware configuration (motherboard, etc..) can have an effect on the reserved size, btw. https://learn.microsoft.com/en-us/windows/win32/memory/virtual-address-space If you are running out of memory at 2.5GB then the IDE is trying to make an allocation of 0.5 GB or more. This seems unlikely so there could be something else going on. You might wait to check the size of "hardware reserved memory" on your system. 100 forms open at the same time is hardly a typical use case. Why would you ever want that? FWIW, I just tried opening all the over 600 forms, frames and datamodules of a project with around 3 million lines of code. It uses DevExpress ribbon, docking, skins, grids, and controls, FireDAC, etc. That consumed 3.4 GB but happily compiled and linked. It's a 64-bit project. I'm not saying that your problem isn't real but I don't think this problem is common enough that it alone justifies migrating the IDE to 64-bit. And I certainly don't think your rhetoric will help your case.

That's not the worst; Installing a component still requires recompiling the IDE. That probably makes sense on Linux, but it makes zero sense on Windows. Also, the LCL and RTL aren't really up to par with Delphi.

Looking at the source of TBitBtn, it can either use an internal TBitmap (which will consume at least 1 handle per button) or it can use an external imagelist (which will consume at least 1 handle globally [*]). [*] Drawing an imagelist in the disabled state consumes another handle, drawing it monochrome another. I would stay away from TBitBtn. It was cute in the nineties but today few people want their application to look like it was made in the nineties...

For comparison, I have a simple application that's using DevExpress ribbon, DevExpress grids and a virtual treeview and it uses 400-450 GDI handles. An imagelist itself uses at most one GDI handle - if any. It's the individual bitmaps that copy data from the image list that uses the handles.

That issue basically just says "Give me a 64-bit version because I say so - or else". I would just close it if I were Embarcadero. But I'm sure that migrating to Lazarus will ensure that you don't have to worry about memory limitations anymore. You will have a whole slew of other problems to keep you busy instead. Good luck with that.

It makes perfect sense to me.

So you don't format your source code with line breaks? - Because the Delphi compiler will ignore them anyway. It's not something I often do, but once in a blue moon I need to have a largish block of text in the source and that's just the way it is. Let's assume that there are reasons for this and that I know what I'm doing.

Can't be much: AFAIK the LCL canvas doesn't support anti-aliasing.

It's just a file format. There's nothing it that limits it to Windows. https://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help#Use_in_non-Windows_applications

I can't tell if this was an attempt at humor because that's exactly the syntax I want to avoid.

Sounds like a bug to me. Have you checked the application for resource leaks?

By Ignore newline I meant from this: Lorem ipsum dolor produce this: lorem ipsum dolor

What docs?

Nice! And about bloody time too! But surely there's more to the CoffeeScript-like syntax than this: Like, how does one differentiate between preserve or trim leading white space and preserve or ignore newline?

https://github.com/CloudDelphi/RTC-Portal-VCL

You might want to link to the source when you copy/paste some text verbatim: http://hunspell.github.io/ In addition to the Hunspell library itself, the Hunspell dictionary format is also supported by many proprietary 3rd party spell check libraries such as the DevExpress spell checker. See also:

Yikes. Nobody touches my screen! Not even myself. Besides touch screens add cost and complexity.

It's a bug in FMX. Probably related to this one: https://quality.embarcadero.com/browse/RSP-39520 It's visible for Stroke.Thickness>1

As far as I remember it had something to do with some pre-Delphi 6 version attempting to parse the {$if ...} even though it was protected by a {$ifdef CONDITIONALEXPRESSIONS}. It could also just have been the fact that {$if CompilerVersion...} doesn't work above the first uses clause... Anyway, it doesn't really matter anymore. It just struck me that there was a reason why the feature didn't gain more use - from me at least.

So, can anyone remember which version of Delphi broke that scheme? It's not broken now, but I'm certain that there was a version after Delphi 6 that somehow broke {$IF} so it couldn't be used if backward and forward compatibility was needed.