v0.5.0

• Switched simd base64 crate for one that works on stable (from vb64 to base64_simd)
• Allow boolean arguments to function as flags, without a true or false argument following the flag itself (#109, thanks @tatounee !)
• Fix cropping issues when zooming out too much while using kitty protocol
• Added gg and G keybindings for scrolling to the top and bottom of a page, respectively, when filling the width of the screen with kitty
• Updated help page to only show kitty keybindings when you're actually using kitty
• Map page-up and page-down keybindings to do the same thing as up-key and down-key (#115, thanks @maxdexh !)
• Vertically center pages within the available space if they are not constrained by the height (#116, thanks @maxdexh !)
• Fixed issue with cooked mode not being restored upon panic/error (#118, thanks @maxdexh !)
• Implemented a debounce for file reload updates to prevent some editors from paralyzing the app due to a flurry of reloads (#117, thanks @maxdexh !)
• Fixed an overflow when zooming out of horizontal pdfs (#119, thanks @maxdexh !)
• Reworked zooming to allow for full zooming in and out and panning in both directions (#121, thanks @maxdexh !)

v0.4.3

• Fix issue with some terminals hanging on startup
• Fix issues with some iterm2-backend terminals not displaying anything
• Allow using ctrl+scroll to zoom in/out while zoomed using kitty backend (#94, thank you @perhurt!)
• (Internal) run CI with --locked flag to ensure lockfile is always in-sync

v0.4.2

• Add --version flag
• Fix shms not working on macos (#93)

v0.4.1

• Add instructions for using new zoom/pan features to help page

v0.4.0

• Update to new kittage backend for kitty-protocol-supporting terminals (fixes many issues and improves performance significantly, see the PR)
• Use new mupdf search API for slightly better performance
• Update ratatui(-image) dependencies
• Allow specification of default white and black colors for rendered pdfs
• Pause rendering every once in a while while there's a search term to enable searching across the entire document more quickly
• Fix an issue with missing search highlights

v0.3.0 - Mupdf Rewrite

0.3.0

• Update ratatui(-image) dependencies
• Enable Ctrl+Z/Suspend functionality
• Rewrite with mupdf as the backend for much better performance and rendering quality
• Support easy inversion of colors via i keypress
• Support for filling all available space with f keypress
• Change help text at bottom into full help page

With regard to the performance, these are the kind of changes we're seeing:

   Compiling tdf-viewer v0.2.0 (/home/june/Documents/coding/personal/tdf)
    Finished `bench` profile [optimized] target(s) in 1.70s
     Running benches/rendering.rs (target/release/deps/rendering-63f7619046d0b14f)
render_full/benches/adobe_example.pdf
                        time:   [43.921 ms 46.470 ms 49.137 ms]
                        change: [-9.8772% -2.8599% +4.2524%] (p = 0.44 > 0.05)
                        No change in performance detected.
Found 2 outliers among 40 measurements (5.00%)
  2 (5.00%) high mild

render_full/benches/example_dictionary.pdf
                        time:   [928.86 ms 933.67 ms 938.67 ms]
                        change: [-41.719% -41.373% -41.049%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 40 measurements (2.50%)
  1 (2.50%) high mild

render_full/benches/geotopo.pdf
                        time:   [399.14 ms 403.13 ms 407.19 ms]
                        change: [-64.450% -64.040% -63.656%] (p = 0.00 < 0.05)
                        Performance has improved.

render_first_page/benches/adobe_example.pdf
                        time:   [20.232 ms 21.225 ms 22.265 ms]
                        change: [-24.649% -19.961% -14.677%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 3 outliers among 40 measurements (7.50%)
  1 (2.50%) low mild
  2 (5.00%) high mild

render_first_page/benches/example_dictionary.pdf
                        time:   [15.449 ms 16.222 ms 17.033 ms]
                        change: [-8.1274% -1.7836% +5.7176%] (p = 0.61 > 0.05)
                        No change in performance detected.
Found 1 outliers among 40 measurements (2.50%)
  1 (2.50%) high mild

render_first_page/benches/geotopo.pdf
                        time:   [47.447 ms 50.062 ms 52.744 ms]
                        change: [+61.358% +73.485% +86.469%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 8 outliers among 40 measurements (20.00%)
  3 (7.50%) low mild
  4 (10.00%) high mild
  1 (2.50%) high severe

only_converting/benches/adobe_example.pdf
                        time:   [3.0548 ms 3.4825 ms 3.9492 ms]
                        change: [-56.335% -46.955% -36.602%] (p = 0.00 < 0.05)
                        Performance has improved.

only_converting/benches/example_dictionary.pdf
                        time:   [223.93 ms 231.58 ms 239.54 ms]
                        change: [-62.939% -61.546% -60.341%] (p = 0.00 < 0.05)
                        Performance has improved.

only_converting/benches/geotopo.pdf
                        time:   [65.724 ms 70.457 ms 75.330 ms]
                        change: [-42.242% -37.122% -32.047%] (p = 0.00 < 0.05)
                        Performance has improved.

Obviously, this all looks quite good, with the exception of render_first_page/benches/geotopo.pdf. This tests how long it takes for the first page of the geotopo test file to appear to the reader, and it's the only test that had any sort of regression (and it's a quite sizeable regression, too).

This is obviously something I'll be looking into in the future, but I don't think it's really any cause for concern right now. Looking at this test, 20% of its recorded measurements were outliers. This is a huge red flag by itself, and when we also look at the other benchmarks that use this file, we see that it's even more of an outlier (since all other benchmarks involving this file improved quite dramatically).

I think this test is just very noisy and unreliable, on top of perhaps causing some sort of edge-case in the mupdf rendering code. It'll be looked into, but I don't think many (if any) users of tdf should see this sort of performance regression. If you do, please file a bug :)