ਚਾਕ ਟੂਲ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ: ਪੂਰੀ-ਸਕ੍ਰੀਨ ਪਾਸਾਂ ਤੋਂ scissor rectangles ਤੱਕ

ਅੰਤਿਮ device build ਉੱਤੇ 255% zoom ਵਿੱਚ ਲਾਲ ਅਤੇ ਨੀਲੀ ਚਾਕ, 155 strokes।

Lulucat Notes ਦੇ ਚਾਕ ਟੂਲ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਇੱਕ ਖਾਸ ਸਮੱਸਿਆ ਸੀ: ਖਾਲੀ ਥਾਂ ਉੱਤੇ ਲਿਖਣਾ ਰਵਾਨੀ ਵਾਲਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਸੀ, ਪਰ ਪਹਿਲਾਂ ਹੀ ਚਾਕ strokes ਨਾਲ ਭਰੇ ਖੇਤਰ ਵਿੱਚ ਜਾਣ ਨਾਲ ਪੈੱਨ ਦੀ ਨੋਕ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦੀ ਸੀ। ਉਸੇ ਖੇਤਰ ਵਿੱਚ ਲਿਖਣਾ ਜਾਰੀ ਰੱਖਣ ਨਾਲ canvas ਨੂੰ ਖਿਸਕਾਉਣਾ ਵੀ ਹੌਲੀ-ਹੌਲੀ ਹੌਲਾ ਹੋ ਜਾਂਦਾ ਸੀ।

ਆਮ ਹੱਥ-ਲਿਖਤ ਵਾਲਾ ਇੱਕ ਪੰਨਾ ਹੀ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਸੀ: 300% zoom, local area ਵਿੱਚ 70 ਦਿਖ ਰਹੇ ਚਾਕ strokes, ਕੁੱਲ 3,571 input sample points। ਖਾਲੀ ਖੇਤਰ ਰਵਾਨੀ ਵਾਲੇ ਰਹੇ; ਸਿਰਫ਼ ਉਹ ਖੇਤਰ ਹੌਲਾ ਹੋਇਆ ਜਿੱਥੇ strokes ਇਕੱਠੇ ਸਨ।

ਸੁਧਾਰ ਤੋਂ ਬਾਅਦ ਉਹੀ ਪੰਨਾ 255% zoom ਉੱਤੇ ਨਵੀਂ ਲਿਖਤ ਲੈਂਦਾ ਰਹਿ ਸਕਦਾ ਹੈ, ਅਤੇ ਪੈੱਨ ਲੱਗਣ ਵੇਲੇ ਤੇ canvas ਖਿਸਕਾਉਣ ਦੌਰਾਨ — ਦੋਹਾਂ ਵਿੱਚ — ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ strokes ਆਪਣੀ ਪੂਰੀ ਸਪਸ਼ਟਤਾ ਕਾਇਮ ਰੱਖਦੇ ਹਨ।

ਅੰਤਿਮ device screenshot, ਕੁੱਲ 155 strokes। ਇਸ zoom level ਉੱਤੇ ਪੈੱਨ ਲੱਗਣ ਜਾਂ canvas ਖਿਸਕਾਉਣ ਨਾਲ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ strokes ਦੀ ਸਪਸ਼ਟਤਾ ਅਸਥਾਈ ਤੌਰ ਉੱਤੇ ਨਹੀਂ ਬਦਲਦੀ।

ਚਾਕ ਨੂੰ scratch texture ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ

ਇੱਕ ਆਮ ਪੈੱਨ ਹਰ ਗੋਲ stamp ਨੂੰ source-over blending ਨਾਲ ink texture ਉੱਤੇ ਸਿੱਧਾ ਜੋੜ ਸਕਦਾ ਹੈ। ਚਾਕ ਦਾਣੇ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਦੀ ਇੱਕ ਪਰਤ ਜੋੜਦੀ ਹੈ: renderer ਪਹਿਲਾਂ ਪੂਰੇ stroke ਲਈ body coverage ਅਤੇ depth ਇਕੱਠੇ ਕਰਦਾ ਹੈ, ਫਿਰ fixed grain texture ਨਾਲ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਥਾਵਾਂ ਨੂੰ ਚਾਕ ਦੀ ਧੂੜ ਮਿਲੇਗੀ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਨਤੀਜੇ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ink ਉੱਤੇ ਜੋੜਦਾ ਹੈ।

ਇਹ scratch texture ਇੱਕ ਚਾਕ stroke ਨੂੰ ਵੱਖਰਾ ਰੱਖਦੀ ਹੈ। ਇਹ ਵੱਖਰਾਪਣ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇੱਕੋ stroke ਦੇ stamps ਬਹੁਤ overlap ਕਰਦੇ ਹਨ; ਜੇ ਹਰ stamp ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ grain-gate ਕੀਤਾ ਜਾਵੇ, ਤਾਂ stroke ਦੀ ਵਿਚਕਾਰਲੀ ਲਾਈਨ ਵਿੱਚ ਰੰਗ ਵਾਰ-ਵਾਰ ਇਕੱਠਾ ਹੋਵੇਗਾ ਅਤੇ sampling density ਬਦਲਣ ਨਾਲ ਚਾਕ ਦੇ ਛੇਦ ਵੀ ਬਦਲ ਜਾਣਗੇ।

ਵੱਡੇ zoom ਉੱਤੇ Lulucat Notes ਮੌਜੂਦਾ viewport ਵਿੱਚ ਦਿਖ ਰਹੇ vector strokes ਨੂੰ ਮੁੜ draw ਕਰਦਾ ਹੈ। ਪੁਰਾਣੀ implementation ਹਰ ਦਿਖ ਰਹੇ ਚਾਕ stroke ਲਈ ਇਹ ਕਦਮ ਕਰਦੀ ਸੀ:

1. ਮੁੱਖ render encoder ਬੰਦ ਕਰਨਾ;
2. scratch texture ਨੂੰ clear ਕਰਨਾ;
3. ਇਸ ਇੱਕ ਚਾਕ stroke ਨੂੰ scratch ਵਿੱਚ draw ਕਰਨਾ;
4. ਮੁੱਖ render encoder ਨੂੰ ਮੁੜ ਖੋਲ੍ਹਣਾ;
5. ਪੂਰੀ-ਸਕ੍ਰੀਨ triangle ਨਾਲ scratch ਨੂੰ drawable ਉੱਤੇ ਮੁੜ ਜੋੜਨਾ।

ਇੱਕ stroke ਦੀ semantics ਸਹੀ ਸੀ, ਪਰ ਕੰਮ ਦਾ ਦਾਇਰਾ ਬਹੁਤ ਵੱਡਾ ਸੀ। iPad ਦਾ drawable 2732×2048 — ਲਗਭਗ 5.6 million pixels — ਸੀ। ਹਰ ਚਾਕ stroke ਇੱਕ scratch pass ਅਤੇ ਇੱਕ ਪੂਰੀ-ਸਕ੍ਰੀਨ composite ਚਲਾਉਂਦਾ ਸੀ। ਸੱਤਰ ਚਾਕ strokes ਦਾ ਮਤਲਬ ਲਗਭਗ 141 render encoders ਅਤੇ 70 ਪੂਰੀ-ਸਕ੍ਰੀਨ composites ਸੀ।

ਦਿਖ ਰਹੇ ਚਾਕ strokes ਦੀ ਗਿਣਤੀ ਨੂੰ ਅਤੇ drawable pixel count ਨੂੰ ਮੰਨੋ। ਸਿਰਫ਼ pixel coverage ਨਾਲ ਵਧਣ ਵਾਲਾ ਕੰਮ ਵੇਖੀਏ ਤਾਂ ਪੁਰਾਣੀ implementation ਲਗਭਗ

ਹਰ ਚਾਕ stroke ਨਾਲ ਇੱਕ fixed render-pass overhead ਵੀ ਆਉਂਦਾ ਸੀ, ਇਸ ਲਈ ਇਹ ਖਰਚਾ ਵੀ ਨਾਲ linear ਤਰੀਕੇ ਨਾਲ ਵਧਦਾ ਸੀ। 3,571 input points ਨੇ ਸਿਰਫ਼ ਦੂਜੇ ਦਰਜੇ ਦਾ ਖਰਚਾ ਦਿੱਤਾ। ਸਥਾਨਕ stroke count ਨਾਲ ਜੋ ਚੀਜ਼ ਵਧਦੀ ਸੀ, ਉਹ ਹਰ stroke ਵੱਲੋਂ ਚਲਾਇਆ ਗਿਆ ਪੂਰੀ-ਸਕ੍ਰੀਨ ਕੰਮ ਦਾ ਦਾਇਰਾ ਸੀ।

ਮਾਪ 12.9-inch iPad Pro (5th generation, M1) ਉੱਤੇ iPadOS 18.6.2 ਨਾਲ ਕੀਤੇ ਗਏ। ਇਸ ਖਾਸ iPad — ਜਿਸ ਨੂੰ ਹੇਠਾਂ LucasPad ਕਿਹਾ ਗਿਆ ਹੈ — ਉੱਤੇ ਉਸੇ viewport ਲਈ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੇ GPU timestamps ਦੀ ਤੁਲਨਾ ਕੀਤੀ, ਅਤੇ ਉਸੇ Debug device build ਵਿੱਚ command-buffer timestamps ਵਰਤੇ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ranges ਕਈ frames ਵਾਲੇ logs ਵਿੱਚ ਆਮ ਉਤਾਰ-ਚੜ੍ਹਾਅ ਹਨ, ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਦਿੱਤੇ ਜਾਣ ਵਾਲੇ version ਦੀ frame-rate commitment ਨਹੀਂ। 70 ਦਿਖ ਰਹੇ ਚਾਕ strokes ਉੱਤੇ ਇੱਕ frame ਨੂੰ ਆਮ ਤੌਰ ਉੱਤੇ 52–60 ms GPU time ਲੱਗਦਾ ਸੀ; ਲਗਭਗ 120 strokes ਵਾਲੇ ਖੇਤਰ ਵਿੱਚ GPU time 77–80 ms ਤੱਕ ਵਧ ਗਿਆ।

Scratch ਅਤੇ composite passes ਦੇ ਪੂਰੀ-ਸਕ੍ਰੀਨ rectangles ਦੇ area ਤੋਂ ਅਨੁਮਾਨ ਲਗਾਈਏ ਤਾਂ ਹਰ frame ਦਾ theoretical work scope ਲਗਭਗ 783 million pixels ਤੋਂ 1.34 billion pixels ਤੱਕ ਵਧਿਆ। ਇਹ rectangle areas ਦਾ ਜੋੜ ਹੈ ਅਤੇ fragment invocation counts, video-memory read/write bytes ਜਾਂ GPU hardware counters ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। Metal ਦਾ fast clear, attachment load/store ਅਤੇ pass switching ਅਜੇ ਵੀ GPU ਅਤੇ driver ਦੇ control ਹੇਠ ਹਨ।

ਇਹ ਵੀ ਸਮਝ ਆਉਂਦਾ ਹੈ ਕਿ ਖਾਲੀ ਖੇਤਰ ਰਵਾਨੀ ਵਾਲੇ ਕਿਉਂ ਰਹੇ। Visibility culling viewport ਤੋਂ ਬਾਹਰਲੇ strokes ਨੂੰ ਛੱਡ ਦਿੰਦੀ ਹੈ; ਖਾਲੀ ਖੇਤਰ ਵਿੱਚ ਲਗਭਗ zero ਹੁੰਦਾ ਹੈ, ਜਦਕਿ ਘਣੇ ਖੇਤਰ ਵਿੱਚ ਵਧਦਾ ਰਹਿੰਦਾ ਹੈ।

0.85 ms ਉੱਤੇ ਇੱਕ ਗਲਤ ਜਵਾਬ

App ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਪੂਰੇ ਪੰਨੇ ਦੀ ink texture ਸੀ, ਜੋ ਪ੍ਰਤੀ point ਦੋ pixels ਉੱਤੇ baked ਕੀਤੀ ਗਈ ਸੀ। ਲਿਖਣ, canvas ਖਿਸਕਾਉਣ ਅਤੇ zoom ਕਰਨ ਦੌਰਾਨ ਇਸ texture ਨੂੰ ਸਿੱਧਾ ਦਿਖਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ; ਸਿਰਫ਼ ਮੌਜੂਦਾ Apple Pencil stroke ਨੂੰ live vector ਰੱਖਿਆ। Interaction ਮੁੱਕਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਹੋਰ frame ਵਿੱਚ high-resolution vector result ਮੁੜ render ਕੀਤਾ ਜਾਂਦਾ ਸੀ।

ਇਹ ਤਰੀਕਾ ਬਹੁਤ ਵਧੀਆ ਚੱਲਿਆ। 300% zoom ਵਾਲੇ ਉਸੇ ਘਣੇ ਖੇਤਰ ਵਿੱਚ GPU time 0.84–0.85 ms ਤੱਕ ਘਟ ਗਿਆ ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਚਾਕ strokes ਦੀ ਗਿਣਤੀ ਨਾਲ ਵਧਣਾ ਬੰਦ ਹੋ ਗਿਆ।

ਪਰ ਅਸਲ device ਉੱਤੇ ਸਮੱਸਿਆ ਵੀ ਉਤਨੀ ਹੀ ਸਪਸ਼ਟ ਸੀ। 300% zoom ਉੱਤੇ ਹਰ point ਲਈ ਲਗਭਗ ਛੇ screen pixels ਚਾਹੀਦੇ ਸਨ, ਪਰ cache ਸਿਰਫ਼ ਦੋ ਦਿੰਦੀ ਸੀ। Apple Pencil ਦੇ screen ਨੂੰ ਛੁਹਿੰਦੇ ਹੀ ਸਾਰੇ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ strokes ਇੱਕ ਨਰਮ, low-resolution image ਬਣ ਜਾਂਦੇ ਸਨ; Pencil ਚੁੱਕਣ ਉੱਤੇ ਉਹ ਪੂਰੀ ਸਪਸ਼ਟਤਾ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਂਦੇ ਸਨ।

Tester ਨੇ ਇੱਕ ਗੱਲ ਕਹੀ: “ਜਦੋਂ ਮੈਂ ਲਿਖਦਾ ਹਾਂ, ਸਾਰਾ canvas ਧੁੰਦਲਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਛੱਡਦੇ ਹੀ ਇਹ ਮੁੜ ਸਾਫ਼ ਹੋ ਜਾਂਦਾ ਹੈ।”

ਇਹ optimization ਹਟਾ ਦਿੱਤੀ ਗਈ। 0.85 ms ਸਭ ਤੋਂ ਘੱਟ ਮਾਪਿਆ ਗਿਆ ਨਤੀਜਾ ਸੀ, ਪਰ ਇਹ ਕਬੂਲਯੋਗ ਚਾਕ ਟੂਲ ਨਹੀਂ ਸੀ। ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ strokes ਲਿਖਣ ਦੇ feedback ਦਾ ਹਿੱਸਾ ਹਨ; ਪੈੱਨ ਲੱਗਣ ਵੇਲੇ ਉਨ੍ਹਾਂ ਦੀ ਸਪਸ਼ਟਤਾ ਨਹੀਂ ਬਦਲ ਸਕਦੀ।

ਹਰ ਚਾਕ stroke ਨੂੰ ਆਪਣੇ rectangle ਤੱਕ ਸੀਮਿਤ ਕਰਨਾ

ਅੰਤਿਮ ਸੁਧਾਰ ਨੇ ਹਰ stroke ਲਈ scratch ਅਤੇ compositing ਨੂੰ ਕਾਇਮ ਰੱਖਿਆ ਅਤੇ ਸਿਰਫ਼ pixel work ਦਾ ਦਾਇਰਾ ਘਟਾਇਆ। ਹਰ stroke ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ canvas bounding box ਸੀ, ਜੋ ਉਸ ਦੇ ਸਾਰੇ stamp radii ਦੇ union ਤੋਂ ਬਣਿਆ ਸੀ। Renderer ਇਸ bounding box ਨੂੰ ਮੌਜੂਦਾ viewport ਦੇ drawable coordinates ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਅਤੇ antialiasing margin ਲਈ ਦੋ pixels ਵਧਾਉਂਦਾ ਹੈ:

ਉਹੀ scissor rectangle ਤਿੰਨ ਕੰਮਾਂ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ: scratch ਨੂੰ clear ਕਰਨਾ, stroke draw ਕਰਨਾ ਅਤੇ result ਨੂੰ ਮੁੱਖ surface ਉੱਤੇ ਮੁੜ ਜੋੜਨਾ।

let rect = displayScissorRect(for: stroke.bounds, viewport: viewport)

scratchEncoder.setScissorRect(rect)
clearScratchExplicitly()
drawStrokeIntoScratch(stroke)

mainEncoder.setScissorRect(rect)
compositeChalkFromScratch(stroke)
mainEncoder.setScissorRect(fullDrawable)

4096² ink texture ਦੀ baking ਅਤੇ partial replay ਲਈ ਵੀ ਇਹੀ logic ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਜੋ ਵੱਡੇ zoom ਵਾਲਾ display ਅਤੇ ਸਥਿਰ ਹੋ ਚੁੱਕੀ ink layer ਚਾਕ ਦੇ ਦੋ ਵੱਖਰੇ behavior ਨਾ ਬਣਾਉਣ।

ਇੱਥੇ ਦੋ ਵੇਰਵੇ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਸਕਦੇ ਹਨ।

ਪਹਿਲਾਂ, render pass ਦਾ loadAction = .clear attachment load stage ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਅਤੇ rasterization scissor ਨਾਲ ਸੀਮਿਤ ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਨੂੰ ਵਰਤਦੇ ਰਹਿਣ ਨਾਲ ਪੂਰਾ scratch texture ਫਿਰ ਵੀ clear ਹੋਵੇਗਾ। ਠੀਕ ਕੀਤਾ pass .dontCare ਵਰਤਦਾ ਹੈ ਅਤੇ ਫਿਰ scissor ਦੇ ਅੰਦਰ clear_fragment draw ਕਰਦਾ ਹੈ। ਇਹ rectangle ਬਾਅਦ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ composite ਸਿਰਫ਼ ਉਹੀ rectangle ਪੜ੍ਹਦਾ ਹੈ, ਇਸ ਲਈ attachment ਦਾ ਪੁਰਾਣਾ content load ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ।

ਦੂਜਾ, ਹਰ ਚਾਕ stroke ਦਾ composite ਮੁੱਕਣ ਤੋਂ ਬਾਅਦ ਬਾਹਰਲਾ scissor restore ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਜੇ state restoration ਵਾਲੀ ਇਹ line ਛੱਡ ਦਿੱਤੀ ਜਾਵੇ, ਤਾਂ ਅਗਲੇ pens, images ਜਾਂ selections ਪਿਛਲੇ ਚਾਕ stroke ਦੀਆਂ ਹੱਦਾਂ ਨਾਲ clipped ਰਹਿਣਗੇ ਅਤੇ missing strokes ਜਾਂ missing images ਵਾਂਗ ਦਿਸਣਗੇ।

ਚਾਕ ਦਾ grain ਅਜੇ ਵੀ rectangle ਦੇ local UVs ਤੋਂ ਨਹੀਂ, ਸਗੋਂ absolute canvas coordinates ਤੋਂ sample ਹੁੰਦਾ ਹੈ। Scissor ਹਿਲਾਉਣ ਨਾਲ ਸਿਰਫ਼ ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ GPU ਕਿਹੜੇ pixels process ਕਰਦਾ ਹੈ; ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਹਰ pixel grain texture ਦੀ ਕਿਹੜੀ ਥਾਂ ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ। ਇਸ ਲਈ ਨਾਲ-ਨਾਲ ਵਾਲੇ rectangles ਵਿੱਚ texture seams ਨਹੀਂ ਬਣਦੇ ਅਤੇ canvas ਖਿਸਕਾਉਣ ਨਾਲ grain ਨਹੀਂ ਸਰਕਦਾ।

ਸਿਰਫ਼ pixel workload ਵੇਖੀਏ ਤਾਂ ਨਵਾਂ work scope ਲਗਭਗ

ਦੇ ਨੇੜੇ ਹੈ, ਜਿੱਥੇ ਮੌਜੂਦਾ screen ਉੱਤੇ ਵੇਂ ਚਾਕ stroke ਦੇ axis-aligned bounding-box ਦਾ area ਹੈ। Render encoders ਦੀ ਗਿਣਤੀ ਘਟੀ ਨਹੀਂ, ਪਰ ਹਰ clear ਅਤੇ composite ਹੁਣ stroke ਦੇ screen bounding box ਤੱਕ ਸੀਮਿਤ ਹੈ।

ਇੱਕੋ ਰੰਗ ਵਾਲੇ ਚਾਕ strokes ਨੂੰ batch ਕਿਉਂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ

ਪੰਨੇ ਉੱਤੇ ਜ਼ਿਆਦਾਤਰ ਚਾਕ strokes ਦਾ ਰੰਗ ਅਤੇ density ਇੱਕੋ ਹੈ, ਇਸ ਲਈ ਦਰਜਨਾਂ strokes ਨੂੰ scratch ਵਿੱਚ ਇਕੱਠੇ draw ਕਰਕੇ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ composite ਕਰਨਾ ਆਕਰਸ਼ਕ ਲੱਗਦਾ ਹੈ। ਇਸ ਨਾਲ render passes ਹੋਰ ਘੱਟ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ overlap ਵਾਲੇ ਖੇਤਰਾਂ ਵਿੱਚ ਰੰਗ ਅਤੇ grain ਦੀ semantics ਬਦਲ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਜਾਣ-ਬੁੱਝ ਕੇ ਸਰਲ ਕੀਤਾ ਮਾਮਲਾ ਲਓ: ਇੱਕ pixel ਉੱਤੇ ਦੋ strokes ਦੀ grain-gate value ਇੱਕੋ ਹੈ, ਅਤੇ body coverages ਤੇ ਹਨ। ਅਸਲ shader ਵਿੱਚ gate ਹਰ stroke ਦੀ pressure depth ਉੱਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ; batching ਆਮ ਤੌਰ ‘ਤੇ equivalent ਨਹੀਂ ਹੁੰਦੀ, ਇਹ ਦਿਖਾਉਣ ਲਈ ਇਹ ਹੋਰ ਸਰਲ ਮਾਮਲਾ ਹੀ ਕਾਫ਼ੀ ਹੈ। ਮੌਜੂਦਾ per-stroke compositing ਦਿੰਦੀ ਹੈ

ਜਦਕਿ ਪਹਿਲਾਂ bodies ਨੂੰ merge ਕਰਕੇ ਫਿਰ ਇੱਕ gate ਲਗਾਉਣ ਨਾਲ ਮਿਲਦਾ ਹੈ

ਫ਼ਰਕ ਹੈ। ਜਦੋਂ ਦੋ strokes overlap ਕਰਦੇ ਹਨ ਅਤੇ grain gate ਨਾ ਪੂਰਾ zero ਹੁੰਦਾ ਹੈ ਨਾ ਪੂਰਾ one, ਨਤੀਜੇ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਸਿੱਧਾ batch ਕਰਨ ਨਾਲ crossing ਵਾਲੀਆਂ ਥਾਵਾਂ ਉੱਤੇ ਚਾਕ ਦੀ ਧੂੜ ਪੈਣ ਦਾ ਢੰਗ ਬਦਲ ਜਾਂਦਾ।

ਸਹੀ batching ਲਈ ਇਹ ਸਾਬਤ ਕਰਨਾ ਪਵੇਗਾ ਕਿ strokes ਦੇ pixels ਆਪਸ ਵਿੱਚ disjoint ਹਨ, ਜਾਂ ਹਰ stroke ਲਈ ਵੱਖਰਾ atlas region ਦੇ ਕੇ ਮੂਲ ਕ੍ਰਮ ਵਿੱਚ composite ਕਰਨਾ ਪਵੇਗਾ। ਅੰਤਿਮ device acceptance ਵਿੱਚ scissor ਤਰੀਕਾ ਹੀ ਰੱਖਿਆ ਗਿਆ, ਇਸ ਲਈ ਇਸ ਪੜਾਅ ਵਿੱਚ atlas ਜਾਂ ਉਸ ਦੀ management complexity ਨਹੀਂ ਜੋੜੀ ਗਈ।

ਇੱਕ billion pixels ਤੋਂ ਵਾਪਸ ਕੁਝ million pixels ਤੱਕ

ਅੰਤਿਮ device measurements:

ਸਥਿਤੀ	ਸੁਧਾਰ ਤੋਂ ਪਹਿਲਾਂ	Precise scissor
70 ਦਿਖ ਰਹੇ ਚਾਕ strokes, 300% zoom, ਲਿਖਣ ਵੇਲੇ	GPU 52–60 ms	≈ 9–10 ms
≈ 121 ਦਿਖ ਰਹੇ ਚਾਕ strokes, 300% zoom	GPU 77–80 ms	13.7–15.6 ms
ਪ੍ਰਤੀ frame scratch ਅਤੇ composite ਦਾ theoretical rectangle scope	783 M–1.34 B pixels	≈ 1.7 M–3 M pixels

Device document ਦੇ 3,452 strokes ਅਤੇ 202,710 sample points ਨਾਲ clipping boundaries ਵੀ ਜਾਂਚੀਆਂ। 0.5×, 1×, 2×, 3×, 5× ਅਤੇ 8× zoom ਉੱਤੇ 186,408 viewport cases ਬਣਾਏ ਗਏ; ਹਰ ਉਹ point sprite ਜੋ non-zero coverage ਦੇ ਸਕਦਾ ਸੀ, calculated scissor ਦੇ ਅੰਦਰ ਸੀ। ਇਸ ਜਾਂਚ ਵਿੱਚ canvas edges, viewport edges ਅਤੇ offset ਦੀਆਂ ਵੱਖ-ਵੱਖ combinations ਸ਼ਾਮਲ ਸਨ।

ਅੰਤਿਮ code interaction state ਦੇ ਆਧਾਰ ਉੱਤੇ low-resolution LOD ਵੱਲ switch ਨਹੀਂ ਕਰਦਾ। ਘੱਟ zoom ਉੱਤੇ ਪੂਰੇ ਪੰਨੇ ਦੀ ink texture ਅਜੇ ਵੀ ਦਿਖਾਈ ਜਾਂਦੀ ਹੈ; ਵੱਧ zoom ਉੱਤੇ ਦਿਖ ਰਹੇ strokes ਅਜੇ ਵੀ vectors ਵਜੋਂ redraw ਹੁੰਦੇ ਹਨ। Threshold ਦੇ ਇੱਕੋ ਪਾਸੇ ਪੈੱਨ ਲੱਗਣਾ ਜਾਂ canvas ਖਿਸਕਾਉਣਾ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ strokes ਨੂੰ ਕਿਸੇ ਹੋਰ clarity level ਨਾਲ replace ਨਹੀਂ ਕਰਦਾ। ਵੱਧ zoom ਵਾਲੇ vector redraw ਦੌਰਾਨ ਹਰ ਚਾਕ stroke ਦਾ scratch clear ਅਤੇ composite ਸਿਰਫ਼ ਉਸ ਦੇ ਆਪਣੇ screen bounding box ਨੂੰ cover ਕਰਦਾ ਹੈ।

GPU time ਨੇ ਸਪਸ਼ਟਤਾ ਨਹੀਂ ਫੜੀ

GPU ਦੀਆਂ ਕਾਰਗੁਜ਼ਾਰੀ ਸਮੱਸਿਆਵਾਂ data structure ਵਿੱਚ ਸਭ ਤੋਂ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਮਾਤਰਾ ਨਾਲ ਲਾਜ਼ਮੀ ਤੌਰ ਉੱਤੇ ਨਹੀਂ ਵਧਦੀਆਂ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ 3,571 input points ਆਸਾਨ ਸ਼ੱਕੀ ਸਨ; frame time 70 ਚਾਕ strokes ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਲੋਂ ਚਲਾਏ ਪੂਰੀ-ਸਕ੍ਰੀਨ ਕੰਮ ਅਤੇ render-pass switching ਨਾਲ ਤੈਅ ਹੁੰਦਾ ਸੀ।

ਦ੍ਰਿਸ਼ਟੀਗਤ semantics ਨੇ ਉਪਲਬਧ optimizations ਨੂੰ ਵੀ ਸੀਮਿਤ ਕੀਤਾ। ਹਰ stroke ਦਾ ਆਪਣਾ scratch, ਮੂਲ compositing order ਅਤੇ canvas grain ਦੇ absolute coordinates ਮਨਮਰਜ਼ੀ ਨਾਲ ਨਹੀਂ ਹਟਾਏ ਜਾ ਸਕਦੇ ਸਨ। ਇੱਕੋ ਰੰਗ ਅਤੇ ਇੱਕੋ density ਸਿਰਫ਼ ਇਹ ਦੱਸਦੇ ਹਨ ਕਿ parameters ਮਿਲਦੇ ਹਨ — ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ ਕਿ overlap ਵਾਲੇ ਨਤੀਜੇ merge ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਅਸਲ device ਤੋਂ ਮਿਲੇ feedback ਨੇ ਸਭ ਤੋਂ ਘੱਟ GPU time ਵਾਲੇ version ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ। “ਸਾਰਾ canvas ਧੁੰਦਲਾ ਹੋ ਜਾਂਦਾ ਹੈ” ਵਾਲੀ ਟਿੱਪਣੀ ਨੇ ਉਹ product constraint ਦੱਸੀ ਜੋ measurement ਇਕੱਲੀ ਨਹੀਂ ਦੱਸ ਸਕੀ ਸੀ: Apple Pencil screen ਨੂੰ ਛੁਹਿੰਦੇ ਸਮੇਂ ਵਰਤੋਂਕਾਰ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ strokes ਨੂੰ ਵੀ ਦੇਖ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।

ਅੰਤਿਮ version ਕੋਈ ਨਵੀਂ interaction cache layer ਨਹੀਂ ਜੋੜਦਾ ਅਤੇ ਸਪਸ਼ਟਤਾ ਘਟਾਉਂਦਾ ਨਹੀਂ। ਵੱਧ zoom ਉੱਤੇ vector redraw ਸਿਰਫ਼ ਹਰ ਚਾਕ stroke ਦੇ ਕੰਮ ਨੂੰ ਉਸ ਦੇ ਆਪਣੇ screen bounding box ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। LucasPad ਉੱਤੇ ਮੁੜ load ਕਰਨ ਤੋਂ ਬਾਅਦ feedback ਸੀ: “ਬਹੁਤ ਵਧੀਆ ਲੱਗਦਾ ਹੈ।”