Fixed
Status Update
No update yet.
Comments
tn...@google.com
Here's another screenshot, this is from the old Studio implementation of this; I think this is the non-rectangular packing algorithm.
tn...@google.com
And finally here's the rectangular packing algorithm - notice again how we've maximized the thumbnails to take up as much of the available space as possible; that's the essence of this feature request -- to reduce padding and space between the thumbnails to fit as many as possible on the screen simultaneously.
tn...@google.com
Excellent, thanks for doing this!
Out of curiosity, what happens when the screens aren't all the same size, e.g. when you vary by phone type?
Out of curiosity, what happens when the screens aren't all the same size, e.g. when you vary by phone type?
ch...@google.com
They fill the space depends on the phone size. so different rows may have different column numbers.
Demo is always a better explaining:https://drive.google.com/a/google.com/file/d/1sHVd27mC-BlWIGk4raykBf_fYigMtYy5/view?usp=sharing
(Also we layout it regardless the vertical spaces. I think this is more intuitive.)
Demo is always a better explaining:
(Also we layout it regardless the vertical spaces. I think this is more intuitive.)
Description
There is a lot of whitespace here. If I continue to make the preview window wider, it will start showing two columns. But looking at this screenshot, it's pretty clear that we could fit about twice as many previews into this space.
Currently, I have to do a lot of vertical scrolling; I can't simply glance over at the preview to see what the layout looks like. I think we should try to pack this much more tightly to try to optimize this for seeing as much as possible.
It would mean switching to a more complicated packing algorithm. Doing a completely optimal packing is probably very expensive (intuitively it feels like it might be the Knapsack problem), but we have many things we can do to make it simpler.
For example, what if we force the widths to all be the same (by applying a different scaling factor to each preview). In that case, all devices with the same aspect ratio would also have the same height, and we can pack them into a pretty tight grid. But having the same height isn't important -- we can also tighly pack the previews into columns; this is what Google Keep does (try adding a bunch of notes with different lengths).
Even without scaling the previews differently, another approach is to simply try to place previews where they fit, greedily. This would probably be a recursive algorithm, starting out with the available workspace, then iterating through the views and finding the next available area, and then subtracting that from the available space.
As an example of a more tight packing take a look at the screenshot in the following blog entry (from the old Eclipse tooling):
In that implementation we had a couple of different code paths -- one optimized for the case where all the previews have the same size (that's the case for things like vary-by-locale), and another for when they were of different size (like different screens).