Sync gd 2 4 - #22532
Conversation
…ns (90% rewrite). update reference images (buggy before) for tests
…ns usuable, using linear RGBA instead of previous weird squared distance
…p's config. also move it to the right place
This reverts commit add1983. wrong changes. only pkg config needed
|
Great. All public feedback processed. Let me know if there is anything I can help with still @bukka. You're also on /cc for the other discussion. So 👍 from my side so far |
TimWolla
left a comment
There was a problem hiding this comment.
please refrain yourself to slip in changes not related to the topic at hand. Adding you as code owner could be done in a separate PR.
@pierrejoye I agree with David here. Can you commit the CODEOWNER change (and any other change that is not purely related to the GD sync) separately, please?
reverted. |
|
Thanks. As for the sync itself: Is it possible to automate the sync with a script similar to https://github.com/php/php-src/blob/master/ext/lexbor/patches/update-lexbor.sh? This would make verification and future synchronization much easier. The sync should then also happen in a single commit, since individual commits for individual components will result in an inconsistent state for intermediate commits. |
| /* Keep PHP's historical PNG warning text while bundled gd_png.c stays | ||
| * identical to upstream libgd. */ | ||
| if (strcmp(format, "gd-png: fatal libpng error: %s\n") == 0) { | ||
| format = "gd-png: fatal libpng error: %s"; | ||
| } else if (strncmp(format, "gd-png error: setjmp returns error condition", | ||
| sizeof("gd-png error: setjmp returns error condition") - 1) == 0) { | ||
| format = "gd-png error: setjmp returns error condition"; | ||
| } |
There was a problem hiding this comment.
I don't think this logic is necessary, there is explicitly no BC guarantee for error messages in PHP.
There was a problem hiding this comment.
Right, but some phpt rely on those. So I keep them the same so tests don't need updates.
Not totally yet. There are a few things I like to change in ext/gd/libgd first to make it possible. The target is to do not need any script at all. Anything that needs to be specific to php will be separate files. The issue now is that we include php's config and other similar headers as well in ext/gd/libgd/, for the php's versions of various libc functions etc. That makes automatic sync more tricky, especially for the APIs transferring memory ownership f.e., or having slighly different signatures. Some uses different types as well, making build not warning free or may affect behaviors in some edge cases. But now, to achieve this will be significantly easier. Adding specific defines, or thin wrappers for those, upstream using the standard libc and php's use php's ones. But that is not the scope of this PR. This PR is soleny about having 2.4 synced here, tests and audits green. I (desperately) wait for this PR to be approved, while it is approved by the last reviewer on internals, by Ilia, and indeed myself lol ;-) The actual PR for 2.4 additions in PHP is what matters here, see https://wiki.php.net/rfc/ext-gd-2.4. Still drafting it, but it already gives a good idea. |
|
just a head up :) @bukka possible to approve here too? approved on internals but it does make it approved here (I try to stick to the process). All issues reported here or by Volker solved but the sec, or sec-like, ones which will be done using the normal fix only and merge to active branches separately in coordination with the respective RMs. Alternatively I can merge tomorrow, so I can push the actual 8.6 addition PR then. is that ok? :) |
|
ok, missed alpha2..... We have an issue with PRs handling, and security+RMs. I will check out what could work better and propose something to internals |
|
This is breaking the Solaris build: |
|
@devnexen could you please look into that Solaris issue. It's preventing us to verify the stream changes so it would be great to have it working soon. |
|
This seems to break VS18 builds (PHP 8.6.0 Alpha 3. x64, both NTS and ZTS) on Windows: php-src/ext/gd/libgd/gd_avif.c Line 591 in 85c26f2 |
|
My bad. I had to upgrade the dependency: libavif-1.4.2 |
|
Will there be a new libgd-2.4.x release before this hits a PHP release? Otherwise the tests that have been updated (e.g. https://github.com/php/php-src/blob/master/ext/gd/tests/bug73291.phpt) will fail with any available external libgd. (In that example, a SKIPIF could probably fix it, but I'm not sure what the maintainers consider essential behavior of the gd extension.) |
1st part of syncing bundled LibGd to ext/gd/libgd # Updated/Fixed - Color Match improvement using Lab* + Delta-E and actual % as input - Fix and improve freetype rendering and merge both php's libgd + libgd "new encoding" - Fix RAMQ rendering - All codecs with conformance tests (upstream, C) - Perceptual difference (upstream C, will be exposed so php's tests can rely on it - libgd codecs include gif, bmp, webp and jxl full support including animation. Tiff read/write multipages. all BMP format supported but OS/2. Many of these additions or changes work already with existing php's apis. 2D vector APIs and all new Codecs or Gd\* APIs will be a separe PR+RFC. See https://wiki.php.net/rfc/ext-gd-2.4
Sync php's libgd to current GD's master, which will be 2.4.0
New APIs
2D vector graphic APIs using FT raster (standalone version)
Share compisitions with existing gd's functions
optionally allow to replace exising composition OPs to be replace by the new accurate ones.
ad gdImageRead* APIs, to read an image from a file/stream, codec selected using known binary signature
Codecs Added:
QOI full support (bundled/no dep)
#796 Initial QOI support, read and write libgd/libgd#1005
JXL + JXL animation
Webp animation and full formats support
Full animated WebP read/write support libgd/libgd#1001
Full TIFF support
Initial TIFF multiple pages support libgd/libgd#1010
GIF animations read and write + Full GIF support
BMP All formats but OS/2
Feature/bmpfullsupport libgd/libgd#999
AVIF animation read and write
UltraHDR support, using libultrahdr, read and write as standalone, or read SD image as gdImage
Feature/ultrahdr libgd/libgd#1003
for formats supporting it, raw metadata read/write APIs. can be then be processed and pushed back)
Updated/Fixed
. Fix RAMQ rendering
WIP:
This is the 1st phase, to ensure it builds correctly in php's CI. And hopefully the new deps will be added as well.
The next phases is to expose the new APIs in php's.