New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-column page layout #4184
Comments
To set number of columns we could have menu items with explicit numbers or add a modal dialog similar to 1 maps to |
The combinations of view options and zoom levels is confusing already and will be even more. It would be good to design a modal dialog for setting those options in a way to provides a UI hint on how things will look. I assume there are programs that already do something like that and we can steal their design. |
We also need to improve our render cache. At the very least significantly bump the number of cached pages because it was designed with assumption it only needs to keep few pages around. With 4 columns and 16 pages visible at a time, we re-render the pages on scroll. Cache eviction logic should be changed. We should unconditionally evict pages rendered at no-longer-valid zoom. But eviction of rendered pages at currently valid zoom should be based on memory used by rendered bitmaps vs. amount of free memory in the system. We should also have a Also, we should increase number of render threads. Our system was designed long time ago and only uses a single thread that picks items to render from a queue. Today it makes more sense to have up to N threads (where N is number of cores). Instead of keeping a rendering thread we could launch them on demand and throttle number of actively working threads via semaphore. Which brings another point: apparently they way I did multi-threading is not how mupdf wants it. Each mupdf-based document has a single All this is big job in itself and probably deserves its own bug / branch but without at least increasing cache size multi-column view will be bad experience for users. |
Another thing: it seems in what is now non-continuous view it also makes sense to provide multiple rows, if the space is there. We also need to decide how to use remaining space: have it as left/right margin, distribute between pages. In HTML there's |
One known issue now. When |
Yes, something like that word dialog but adapted. I would say we need In non-continuous mode it also fits as many rows as will fit in a window. Then instead of I don't want to do grid. That's just a bit too much and makes no sense in continuous mode. Ideally in non-continuous mode we fit as many rows as fits in window or we just stick with current single row. Layout code is tricky and with those additions will get even more tricky. A good time to add tests to verify all permutations. The algo is well defined: it gets width of viewport, layout mode (zoom, fit, continuous or not), number and size of pages at 100%. It calculates the size of the viewport and positions of all pages in it. Currently the code is tied to all other info about pages but could be transformed to only use the layout info / bounding boxes of rectangles (pages) and spit out their position. We could then write unit tests for specific configurations and for ad-hoc testing we could save position of rectangles to text file and then post-process it in Go to generate HTML that visualizes the layout of the page within viewport. There's also an outstanding layout issue that we should address when touching this code. When I wrote layout I assumed that all pages have the same size and therefore for layouts where we auto-fit pages to fit within viewport (window), we need to calculate a single zoom value for all pages. This breaks for non-uniform pages so a single big page in And finally, we have single layout logic for all possible variations, which might be more complex than necessary. Maybe it would be simpler to split the code into trivial layouts (fixed zoom and number of columns) and complex layouts (where we need to calculate zoom for pages to fit them into viewport). |
This is to record work on showing multiple columns. It subsumes #246, #776, #1171
The work is done on
multi-column
branch. It's ok to rebasemulti-column
branch againstmaster
branch and force push, to keep it in sync with master.Desired features:
It requires re-thinking of our
View
options, both in UI and how it's persisted in settings.How do other programs handle this in their UI?
The text was updated successfully, but these errors were encountered: