Repository navigation
test(raster): fill-tools checks first, disabled until FT-3 to FT-5 - #595
Merged
Merged
Conversation
prakashUXtech
added
the
fast-lane
Claude
github-actions
Bot
removed
the
fast-lane
Contributor
|
Fast lane: not eligible. too big: 451 lines, 3 files (max 400 lines, 15 files). This PR now needs normal captain review. |
prakashUXtech
force-pushed
the
lead/fill-tools-ft-1
branch
from
October 19, 2026 01:06
8cfccc4 to
3c3a20e
Compare
prakashUXtech
added
the
fast-lane
Claude
github-actions
Bot
added
the
fast-lane-merged
Contributor
|
Fast lane: merged into dev (400 lines, 3 files, Fast-Check marker). |
Closed
prakashUXtech
added a commit
to qbtrix/creative-apps
that referenced
this pull request
Oct 19, 2026
…rallel (#3126) Moves the creative-core pin from bf5426e to 0de5687, the head of core `main` (green, promoted from dev). The range has the resident-rendering speedups from qbtrix/creative-core#620: the batched composite commits without waiting, the resident dirty check is storage identity instead of a pixel compare, and the Float16 tile upload vectorizes. It also has qbtrix/creative-core#626, which repoints the mutation anchor #620 moved. Core range (58 commits): qbtrix/creative-core@bf5426e...0de5687 Core PRs in the range: qbtrix/creative-core#567 qbtrix/creative-core#568 qbtrix/creative-core#569 qbtrix/creative-core#570 qbtrix/creative-core#571 qbtrix/creative-core#573 qbtrix/creative-core#574 qbtrix/creative-core#575 qbtrix/creative-core#576 qbtrix/creative-core#577 qbtrix/creative-core#578 qbtrix/creative-core#579 qbtrix/creative-core#580 qbtrix/creative-core#581 qbtrix/creative-core#582 qbtrix/creative-core#583 qbtrix/creative-core#584 qbtrix/creative-core#585 qbtrix/creative-core#586 qbtrix/creative-core#587 qbtrix/creative-core#588 qbtrix/creative-core#589 qbtrix/creative-core#590 qbtrix/creative-core#591 qbtrix/creative-core#592 qbtrix/creative-core#593 qbtrix/creative-core#594 qbtrix/creative-core#595 qbtrix/creative-core#596 qbtrix/creative-core#597 qbtrix/creative-core#598 qbtrix/creative-core#599 qbtrix/creative-core#600 qbtrix/creative-core#601 qbtrix/creative-core#602 qbtrix/creative-core#603 qbtrix/creative-core#605 qbtrix/creative-core#606 qbtrix/creative-core#607 qbtrix/creative-core#608 qbtrix/creative-core#609 qbtrix/creative-core#612 qbtrix/creative-core#613 qbtrix/creative-core#614 qbtrix/creative-core#615 qbtrix/creative-core#616 qbtrix/creative-core#617 qbtrix/creative-core#618 qbtrix/creative-core#619 qbtrix/creative-core#620 qbtrix/creative-core#621 qbtrix/creative-core#622 qbtrix/creative-core#623 qbtrix/creative-core#625 qbtrix/creative-core#626 Besides the pin: - `project.yml` gets the same revision, as in #3023. - `PhotoWorkspace.residentComposited` syncs a region's layer tiles across the cores (through `PhotoLayerComposite.inParallel`), as the CPU route renders its tiles. Steps keep their order. On a brush frame that crosses two tiles the sync went from about 0.73 ms to 0.39 ms. - `Tests/render-budgets.md` has the new 8K table and says where a resident brush frame's time goes. 8K brush frame, release on the M2 Pro (median of three runs; the Mac was loaded, with another Photo running): CPU 1.0 ms, GPU-resident 1.4 ms (was 1.7). The GPU route is still behind the CPU. Most of what's left is the display into the presenter's texture, which waits about 0.55 ms for the GPU because the presenter draws from its own queue. Full redraw on the resident route is 31 ms (was 35) and the first picture 166 ms (was 192). Checked locally on macOS: `scripts/bump-core`'s steps at 0de5687. `swift build --build-tests` passed. Every `*ModelTests` target passed except four Library wall-clock budget tests (`oneEditOnSixtyPhotosStaysInBudget`, `cullOneWithinBudget`, `beginImportWithinBudget`, `orderRebuildWithinBudget`), which went over in the parallel run on the loaded Mac and pass when run alone. The brush perf suites (PhotoBrushDisplayTests, PhotoBrushLatencyTests, PhotoBrushInkLatencyTests) passed. With the parallel sync on top, `PhotoModelTests` and `PhotoRenderBackendTests` passed (647 tests), and `PhotoRenderBudgetTests` ran in release with `Tests/SuiteUITests/SegmentedTabsTests.swift` set aside, since it doesn't link in release on SDK 27.
github-actions Bot
pushed a commit
that referenced
this pull request
Oct 20, 2026
This is the last PR of #435 (fill-tools, slice FT-z). Closes #435. ## What `docs/blueprints/core/features/fill-tools.md` (FT-8): the status line now says built. It lists the merged slice PRs: - #568, #589, #595 (FT-a) - #608, #623 (FT-mask) - #612, #622 (FT-grad) - #654 (FT-z) It also lists the review fixes: #649, #650, #683, #688, #689, #765, #766. It records where the code differs from the packet: - The KJ-FT walk checks the gradient buffer on its own, because masks-mattes is not on dev yet. The masked-composite step is #767. - The release budgets run and report, and a miss is recorded as a known issue. Flood fill, colour range and the gradient are still over budget on Linux (#767). The Mac finisher times them. - The 2 bytes per pixel bound is checked on every platform as the flood fill's counted scratch. The resident peak is only printed. - `GradientSpace.linear` keeps its name and means linear-light mixing. - `gradient` and `gradientMap` share one public `PixelBuffer.maxGradientStops` and one hard-edge rule. - Dither applies to the straight colour, before premultiplying. ## Why FT-z closes the feature: the walk and the budgets are already on dev, and this PR marks the packet built. ## Tests This PR changes docs only. `scripts/ci` printed `CI: PASS` on this head, rebased on dev cc27761. The packet's check for FT-8 is "status line says built". Belt-Lead: act-1a157fd0281-warg Feature: fill-tools Slice: FT-z Mutate: 0/0 none (docs only) Fast-Check: pass Head: d188166
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #435 (fill-tools, slice FT-a, task FT-1).
What: adds
FloodFillTests,ColorRangeTestsandRasterGradientTestsinTests/CoreRasterTests/, written from the packet's Acceptance table against the FT-0 stubs (Sources/CoreRaster/Fill/) and the FT-2 fixtures (FillFixtures.swift). Every case carries@Test(.disabled("waits on FT-n")), so dev stays green and each builder only removes the trait.Why: lead.md rule 13, checks before code. Test names match the packet's mutation entries:
FloodFillTests.fourConnectedStopsAtDiagonal,.toleranceIsInclusive,.borderHalfCovered;ColorRangeTests.fallsOffWithDistance,.threeByThreeMean;RasterGradientTests.reflectedMirrors,.angleStartsAtB,.clampsPastEnd.Notes:
borderHalfCoveredcomputes the ring's real distanced(through CoreColor) and fills att = d / 1.5, which makes the packet's soft edge1 - (d - t) / texactly 0.5.regionCoversExactlyItsInteriorkeeps the packet's tolerance 0.1.toleranceIsInclusiveuses.within(0): with<in place of<=, not even the seed is taken.angleStartsAtBpointsbstraight down froma, so an angle measured from the x axis fails it.worstCaseMemory(100 MP) builds its buffer inside the body only, so skipping it costs nothing. It measures peak RSS growth withgetrusageand allows the 4-byte mask plus 2 bytes per pixel.==) into the region and shape cases to stay within the 400-line cap.FillCheck(OKLab distance, rect pixels, edge ring) lives in FloodFillTests.swift.getrusage/rusagefrom Glibc/Darwin, which I compiled on Linux only.Test that proves it: the three suites compile and
swift test --filter "FloodFillTests|ColorRangeTests|RasterGradientTests"reports all 20 cases skipped with their task id.scripts/ciprinted CI: PASS on this head after the rebase.Belt-Lead: act-1a150b99ea1-n4z4
Feature: fill-tools
Slice: FT-a
Fast-Check: pass
Head: 3c3a20e