On 31.12.2024 at 16:54, Giovanni Giacobbi wrote: > The idea being, can we provide the most expensive operation, that is basic > pixel by pixel comparison, as native function? Otherwise we keep discussing > bikeshedding and years go by without this being available. This does not > stop future more advanced comparison algorithms from being introduced (i.e. > imagediff()).
Okay, I basically agree. And given that this need is not urgent for libgd per se (C clients can write their own functions without having a performance impact), it is in my opionion fine to have some image comparision in our extension binding, not necessarily using a function provided by libgd. > Then we have the transparent pixel. Should equality comparison take >> that into account? Again, in theory, it is not the same as a pixel with >> alpha channel 127, but in practice it may very well be. > > Yes. Overlaying a black 100% opaque pixel is different from overlaying 50% > black pixel, on a non-black surface. Again result is "rendering oriented". Oh, there is some misunderstanding here. In libgd, an alpha channel value of 127 is maximum transparency (same as opacity:0 for CSS). However, I'm talking about the special concept of the transparent pixel (see imagecolortransparent()). This can be an arbitrary pixel value (usually only used for palette images, but also at least partially supported for truecolor images). That pixel value does not even need to have an alpha channel greater than zero (note again, libgd alpha zero is like CSS opacity:1), nor would its RGB values matter. This transparent pixel is typically used with GIF, but also supported for PNG, and maybe some other image formats. > I'm happy to run a quick bechmark and provider results, but my feeling is > we are talking orders of magnitude (without jit, i personally don't > consider it production ready). But I will also benchmarm it with JIT > enabled. Yes, please do some performance comparisons. I didn't notice much difference when working on PR #17305; at least not an order of magnitude. Christoph
