Anders Melander

Yes, that's normal. Right click in the Events pane, select Properties and then unselect Process, Thread and Module messages. Unless you really need the information it's just noise.

Is it a known problem that the VCL misinterprets the valid range of TScrollBar's PageSize and Max properties? TScrollBar enforces the rule that PageSize must be <= Max but Windows requires that PageSize be <= Max-Min+1... This means that if one sets PageSize=Max it is still possible to move the scrollbar +/-1 unit. One work around seems to be to set Min to 1 - because TScrollBar forgets to take Min into account when validating PageSize 🤦‍♂️ https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo

I think the MS documentation, while a bit terse, is clear enough; It specifies how the different properties and their limits relate to each other. The Delphi documentation though is severely lacking. If they had tried to document it properly they would probably have discovered that they got it wrong.

Maybe you should think a bit more about that. Ideally until it is no longer a mystery. What possible reason could there be for that limit? The 16x16 default is a big clue...

BL.Location := FloatRect(x1, y1, x2, y2);

It doesn't; It uses the map file.

Okay. It would be so much easier if you actually read and answered the questions I have asked you. The position and size of the layer determines where the bitmap is drawn. Isn't that what you are seeing?

I have no idea what you mean

And what is the actual result?

Show us what you mean; We still can't read your mind. What does it look like? What do you want it to look like?

My bad. That should have been: BL.Location := FloatRect(ImgView.Bitmap.Width/4, ImgView.Bitmap.Height/4, ImgView.Bitmap.Width/4*3, ImgView.Bitmap.Height/4*3); as a rect is (x1,y1, x2,y2)

I think you forgot the price of a Windows license... I know it's possible to run Windows on a Raspberry Pi, I just don't think it makes sense from a business or performance POW.

If you mean the size of the layer, something like this: // Half size of background bitmap, centered BL.Location := FloatRect(ImgView.Bitmap.Width/4, ImgView.Bitmap.Height/4, ImgView.Bitmap.Width/2, ImgView.Bitmap.Height/2);

Okay, but: And don't include the exe or dcu files in your zip. Also, a description or a mockup of what you expected the result to be would also be needed; I can't read your mind. That said, You are not specifying the size/position of the bitmap layer. The size of the PNG (4774x4345) is much larger than the size of the background (1920x1247). That in itself is not a problem but the size does seem pretty excessive.

That sounds like a horrible idea. Why on earth would you run a desktop/server OS on an embedded device?

Without knowing the size of the base and layer bitmap I can't tell how their relative sizes should be. You have setup the layer scale to follow the base scale (Scaled=True), but have you specified the initial size of the layer? The ugly edges are most likely caused by having DrawMode=dmTransparent. You can experiment with layers and bitmaps using the Imgview_Layers example: If you continue having problems, please create an issue at the Graphics32 issue tracker: https://github.com/graphics32/graphics32/issues Include a minimal, reproducible example.

You don't need to use LoadBitmap32FromPNG; You can just use TBitmap32.LoadFromFile directly and let that figure the format out for you. BL.Bitmap.LoadFromFile('button.png'); Also, you should probably be using dmBlend DrawMode instead of dmTransparent: BL.Bitmap.DrawMode := dmBlend; dmTransparent is for color key transparency (like what TBitmap does). dmBlend is for alpha blending. What do you mean? What size is it? What size should it be?

Actually, that bitmap wasn't directed at your implementation in particular - because I haven't tried it; It's just a bitmap that Octree in general has problems with. But, I'll take it; You're welcome 🙂 The problem is that Octree doesn't reduce the root node (the MSB of the RGB, which represent 2^3=8 color cubes), or move colors between adjacent nodes. So lets say you are reducing an 1 billion pixel image with 1 million red/blue colors+1 green pixel. Octree will represent this as a MSB color cube that only contains a single color (green in this case) with a pixel count of 1 and a bunch of other cubes representing the other 1 million colors/1 billion pixels. If you now reduce this to 16 colors (or any other count for that matter) you will end up with green+15 red/blue colors. And that is just one of the problems with Octree. Of course you can tweak Octree to work around the various issues is has but I feel that that is just polishing a turd. That said, Octree is fast so one just have to be aware of the limitations and only use it when performance is more important than fidelity.

That's Octree, right? How does it deal with this, when reduced from 17 to 16 colors:

The quantizer and dithering in GifImg isn't tied the GIF format; It's completely independent. It is limited to max 256 colors though (AFAIR). I don't think you should start by inventing your own quantization algorithm. Start with one of the known ones so you at least can learn the problem space first (and avoid the usual mistakes). Here's a few links to get you started: RgbQuant.js: color quantization lib https://github.com/leeoniya/RgbQuant.js nQuantCpp: top 6 color quantization algorithms https://github.com/mcychan/nQuantCpp/ Top 3 color quantization algorithms (same author as above, older article) https://www.blackslate.io/articles/color-quantization-algorithm A good one to start with is Xialoin Wu's algorithm (https://www.ece.mcmaster.ca/~xwu/cq.c) It performs well, with good results, and the algorithm is fairly simple. I think that is also the one I will implement next (when I get time; there's far to many interesting projects to work on). This one is also a good read: https://bottosson.github.io/posts/colorwrong/ I will see if I can find time to wrap some code up for you. It's a pluggable framework so you can extend it with new quantization, dithering, and color lookup algorithms, and color spaces. As far as I remember there are no dependencies on Graphics32. Here it is in action (using Linear RGB color space AFAIR):

https://github.com/graphics32/graphics32/blob/78279b925c6110000666af7b3b48e76090f36289/Source/GR32_Blend.pas#L137 https://graphics32.github.io/Docs/Units/GR32_Blend/Routines/ColorScale.htm function ColorScale(F, B: TColor32): TColor32; The functions in the JCL were copied from Graphics32. Use the one in Graphics32 instead. Yes I do. I've been working on getting it ready for release and integration into Graphics32 for several years. The dithering works fine but I'm not satisfied with the quality of the accompanying Octree quantizer I've implemented so it has all been postponed until I have implemented something better. FWIW, I'm not using any of the above color distance functions since the color mapping is implicit with the Octree algorithm (the one I'm using anyway). I'm also not quantizing and dithering in sRGB color space (sRGB is what you'd normally just call RGB). Instead I'm either using the Linear RGB (gamma corrected RGB) or OKlab color spaces. OKlab appears to be the best there is right now for perceptual color mapping and distance. If your quality requirements aren't too strict you can just use my old quantizer (also Octree) and dithering routines in the GifImg unit: https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Imaging.GIFImg.ReduceColors

Ah, yes I see your point. Interesting. A bit labor intensive though, having to vet all the different solutions. Personally, I use another approach 🙂

Ouch! I use that a lot. 9182 occurrences in the project I'm working on right now. I guess that just aborted our migration to Delphi 12 - again.

Do you really want your code to be generated based on fuzzy statistics? How do you even verify the correctness of the results? I'd like mine to be based on strict patterns and known deterministic properties of those patterns. I think trying to solve these problems with AI is a bit like when some companies moves their stuff to the cloud; They don't understand how it works or know what is going on but now it's somebody else's problem.

I have it and many of the techniques in it that were great 10-15 years ago are totally unnecessary today and even detrimental with modern CPUs. It's still a good read and even though some techniques are obsolete, knowing them can help solving other similar problems simply because they can make you think about problems differently. Um... Always? There used to be a time, not that long ago, when integer math was far superior to floating point math (see: Hackers Delight). Not so anymore. via https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware The video is a bit long so I haven't watched it yet, but it's LEA: Load Effective Address, "LEAL" is AT&T syntax for LEA (Intel syntax). Here's a good comment on the topic by Peter Cordes: Using LEA on values that aren't addresses / pointers? Before you start replacing all your shifts with LEA you should be aware that it isn't always faster. As with almost everything in modern CPUs it depends on what the CPU is otherwise busy with. https://stackoverflow.com/questions/70316686/assembly-why-is-lea-eax-eax-eaxconst-shl-eax-eax-const-combined-fast