3 ms·

Would you possibly have a link to a sufficiently complex PDF document? I've not encountered one in a while.

int_19h 6y ago
"Sufficiently complicated" can mean different things. E.g. a document that's long enough, or one that has a lot of vector primitives in it (basically PDF as a vector graphics format). For the former, ISO C++ drafts are a good test case. For example, here's C++20 final draft - 1841 pages: https://isocpp.org/files/papers/N4860.pdf https://isocpp.org/files/papers/N4860.pdf However, when I tried this in Chrome and Firefox, Firefox not only loaded it just fine, but it is also noticeably faster when scrolling. For the second, USGS publishes their topographic maps as free PDFs. These have several layers, one of which is the vectorized map, and another is satellite bitmaps. https://store.usgs.gov/filter-products?sort=relevance&scale=1%3A24%2C000&type=US+Topo&lq=pdf https://store.usgs.gov/filter-products?sort=relevance&scale=... The ones with a lot of roads and contour lines (i.e. any city that's on hills) take a while to rasterize. Say, Seattle: https://store.usgs.gov/product/499688 https://store.usgs.gov/product/499688 This one is so slow in Chrome, it's practically unusable - if you zoom in and try to pan around, it can take over a second for it to actually move. This despite the fact that it doesn't even render the satellite layer. In Firefox, you get the satellite layer (and no way to turn it off, so far as I can tell), and yet it feels more responsive. I think it's because the viewport is always adjusted immediately - actual rendering still takes a while to catch up. In Adobe Reader the rendering keeps up with scrolling, so long as the satellite layer is not enabled. If it is, it gets jerky when rendering any part for the first time. But it seems to be doing better at caching rendered parts of the document - once it's all rendered, it's smooth panning all around. Chrome and Firefox readers both keep re-rendering parts that go out of view and then back, if you scroll far enough.

"Sufficiently complicated" can mean different things. E.g. a document that's long enough, or one that has a lot of vector primitives in it (basically PDF as a vector graphics format). For the former, ISO C++ drafts are a good test case. For example, here's C++20 final draft - 1841 pages: https://isocpp.org/files/papers/N4860.pdf https://isocpp.org/files/papers/N4860.pdf However, when I tried this in Chrome and Firefox, Firefox not only loaded it just fine, but it is also noticeably faster when scrolling. For the second, USGS publishes their topographic maps as free PDFs. These have several layers, one of which is the vectorized map, and another is satellite bitmaps. https://store.usgs.gov/filter-products?sort=relevance&scale=1%3A24%2C000&type=US+Topo&lq=pdf https://store.usgs.gov/filter-products?sort=relevance&scale=... The ones with a lot of roads and contour lines (i.e. any city that's on hills) take a while to rasterize. Say, Seattle: https://store.usgs.gov/product/499688 https://store.usgs.gov/product/499688 This one is so slow in Chrome, it's practically unusable - if you zoom in and try to pan around, it can take over a second for it to actually move. This despite the fact that it doesn't even render the satellite layer. In Firefox, you get the satellite layer (and no way to turn it off, so far as I can tell), and yet it feels more responsive. I think it's because the viewport is always adjusted immediately - actual rendering still takes a while to catch up. In Adobe Reader the rendering keeps up with scrolling, so long as the satellite layer is not enabled. If it is, it gets jerky when rendering any part for the first time. But it seems to be doing better at caching rendered parts of the document - once it's all rendered, it's smooth panning all around. Chrome and Firefox readers both keep re-rendering parts that go out of view and then back, if you scroll far enough.