search

AngusJohnson / Image32

An extensive 2D graphics library written in Delphi Pascal
Boost Software License 1.0
137 stars 31 forks source link

Fix x64 compile error #88

Closed ahausladen closed 2 months ago

ahausladen commented 2 months ago

Fix x64 compile error with the "w" => "width" change.

AngusJohnson commented 2 months ago

Yep, I spotted that too. Should be fixed now. I was initially confused by what "w" represented, thinking that it was "weight" rather than "width" (hence the change). I also changed BlendToAlphaLineWeight to BlendToAlphaLineX86 which I suggest is less confusing, but I'm happy to be corrected if I've misunderstood something there.

ps: I'm very much enjoying / appreciating the speed improvements you have achieved too!

ahausladen commented 2 months ago

Yep, I spotted that too.

You also spotted the bug in BlendBlueChannelLine. That function was so simple that I forget to test it and it doesn't use the "negative index" trick.

ps: I'm very much enjoying / appreciating the speed improvements you have achieved too!

I'm now at a point where the FillChar() calls from SetLength(color32array) bubble up in the profiler. They are mostly useless because the whole array is overwritten by the caller's code. So the additional "fill with zeros" code could be omitted.

And then there are the other two things: The SVG parser and the TDrawData change.

AngusJohnson commented 2 months ago

Yeah, I'm somewhat embarrassed by my SVG code, but at least it works.

ahausladen commented 2 months ago

Your code isn't bad, but the Delphi optimizer is. In Delphi you always have to know what the compiler generates to get fast code. In C++, C# or Java you don't have to go that extra mile. The compiler will do it for you.

The "better CPU register usage" optimizations are all on the compiler with its inability to optimize the code better. And the algorithmic optimizations ("Code that you don't call, won't take time") are an afterthought. The initial algorithm wasn't wrong and only throwing lots of data to it will show where the bottle necks are. For "small" SVG images you won't be able to measure the performance improvements. It could also happen that "small" SVGs are now rendered slower than before, but you wouldn't notice that because it is in the margin of error when measuring the time.

BTW: The Koppen-Geiger_Map_Cfc_present.svg file rendering is now down to 9 seconds on my computer with all the changes. As far as I remember, we started with 22 seconds or more.