Anders Melander

No, He means this:

That's one interpretation but just because the Wikipedia page states it (unsourced, incidentally) doesn't make it so. Another is that it's the most pirated version (the last version without license activation). Yet another is the self-goal of Delphi 8. It's impossible to know. Funnily, if you follow the edits on the wiki, the section you quoted at one point stated:

Ah, yes. Forgot about that one. It's too bad your changes from Martin Offenwanger's version predate the Git repo. That makes it pretty impossible to identify the changes. It does look like they have been updated independently since the fork though. FWIW, I can see you have a fix similar to mine in your version. I do think it's fairly well-documented but I will agree that it's pretty complex and not for the faint of heart (The implementation of it, that is. The use is trivial). I think my attitude toward it would be: If it works right away use it, otherwise don't bother with it. As I wrote, I've been using it for years without any problems.

I've been loading DLLs from resources for years using Martin Offenwanger's BTMemoryModule: https://github.com/DSPlayer/memorymodule It's a Pascal port of Joachim Bauch's solution: https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/ I have a small patch that I have never gotten around to committing to the BTMemoryModule repo. If you elect to go the BTMemoryModule route let me know and I will push a pull request to the repo.

Yes, you did. My bad. Time for bed 🙂

Have you benchmarked this against some of the existing Gaussian blur implementations? It's a bit difficult to decode the algorithm you use due to the lack of comments in the source but it appears you are just applying a Gaussian kernel (with some additional logic) and that approach is usually quite slow. I have a benchmark suite that compares the performance and fidelity of 8 different implementations. I'll try to find time to integrate your implementation into it. With regard to the ratio between Radius and Sigma, it's my understanding that: Ratio = 1 / FWHM (Full Width at Half Maximum) = 1 / (2 * Sqrt(2 * Ln(2))) = 0.424660891294479 But you have a ratio of 0.5 Have I misunderstood something?

It looks to be one of the most underwhelming releases I've seen in a while.

It is a portable computer that goes with me everywhere. So it restarts for almost every few days. it is a Lenovo server very powerful. One of these things is not like the other. One of these things doesn't belong...

Oh, you think? Yes, of course you can do that. You don't need a special library to decode a jpeg in a thread.

Yes, but not that different. There's a difference of 14,307,328 bytes between his two files and one of them has an extra PE section... Anyway, if he can't be bothered to compare the files in a proper tool and tell us what that extra section contains, then I think I'll spend my time on something else; The lawn needs mowing.

I have no idea about what you are trying to say here. I don't speak Haiku...

https://petoolse.github.io/petools/

If you can, try to determine the type and content of the extra PE section.

Do you use madExcept, Eurekalog, or something like that? It could be that something modifies the exe post-link. It could also just be something not so nice adding its own payload to your application...

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.