pixo

Summary There's a critical bug in in the method that causes incorrect data position advancement when handling invalid matches (distance=0, length>1). This leads to tokens being created from wrong positions in the source data. Location File: Method: Lines: ~945-955 Bug Description When the optimal parsing DP produces an invalid match (distance=0 with length>1), the current code treats it as a literal but incorrectly advances by the full instead of just 1: What happens: 1. When : Emits literal at position 0, then advances by 5 bytes 2. Next token tries to read from position 5 instead of position 1 3. Subsequent literals read from wrong positions Expected behavior: A literal should always advance by exactly 1 byte, regardless of the value in the DP array. Proposed Fix Test Case I've written a test that demonstrates the bug: This test currently fails with the bug, demonstrating that is incorrectly advanced. Impact Severity: Critical Scope: Affects optimal LZ77 parsing ( method) Consequence: Incorrect token sequences that don't match the original data When triggered: When the DP solver produces invalid matches (rare but possible with certain data patterns and cost models) Additional Context This bug is defensive code handling an edge case (distance=0 matches shouldn't normally occur from a correct DP solution), but when it does occur, the handling is incorrect. The fix ensures that even in edge cases, the reconstruction is correct. Would you like me to submit a PR with this fix? I can include the test case and verification that all existing tests still pass.

Summary Fixes a critical bug in where is incorrectly advanced when handling invalid matches (distance=0, length>1). Problem When the optimal parsing DP produces an invalid match with and , the existing code treats it as a literal but advances by the full match length instead of just 1 byte. This causes subsequent tokens to read from incorrect positions in the source data. Example: Token 1: → Emits literal at position 0, advances by 5 (should be 1) Token 2: → Tries to read from position 5 instead of position 1 (wrong!) Solution Changed the code to always advance by exactly 1 byte for literals, regardless of the value in the DP arrays: Changes Made Fixed advancement logic in Added comprehensive regression tests Added test for valid match handling (ensure fix doesn't break existing behavior) All existing tests pass Code is well-commented explaining the fix Testing Added two new tests in a dedicated regression test module: 1. * Tests the exact bug scenario with invalid matches Verifies tokens are created from correct positions This test fails without the fix, passes with it 2. Ensures the fix doesn't break valid match handling Tests normal operation with proper distance values [!NOTE] Fix: now treats invalid matches (, ) as a single literal and advances by exactly 1, preventing misaligned reads. Valid matches still advance by and remain unaffected. Tests*: Adds focused regression tests to cover zero-distance multi-byte cases and verify correct behavior for valid matches. Written by Cursor Bugbot for commit cd5793fbddade992c866c2f63de44a310e9c9c3b. This will update automatically on new commits. Configure here.

When shrinking the image, the smaller image is shown at a different size than the original image, which breaks sliding the divider to view the difference in the compression. I think it should scale the big image down using the browser's native scaling. Chances are it's scaled down anyway. That way it can be seen if there is a significant loss of quality in addition to having a smaller image. Scaling up a scaled down image would be an exception to the rule – normally it would be scaled down in order to be shown at the scaled down size or smaller.