sindresorhus / Gifski

🌈 Convert videos to high-quality GIFs on your Mac
https://sindresorhus.com/gifski
MIT License
7.73k stars 291 forks source link

Dimension dropdown: different values for 20% #196

Open jfeltesse opened 4 years ago

jfeltesse commented 4 years ago

See the two values for 20% in the screenshot: which one is it?

Screen Shot 2020-07-12 at 17 58 53

Version 2.8.0.

sindresorhus commented 4 years ago

The percentages in parens are rounded. The 20% one there is actually 20.83%, but that wouldn't look very nice. I'm happy to consider suggestions on how we can make that clearer.

jfeltesse commented 4 years ago

What's the rationale for having two separate sections in the first place?

sindresorhus commented 4 years ago

The first is a predefined list of common sizes and the second are exact percentages.

kornelski commented 4 years ago

Maybe deduplicate them by percentages? (put in a hashmap using rounded percentage as the key)

kornelski commented 4 years ago

The list could also use trimming: don't suggest HD resolutions (lots of GIF viewers are unprepared for that, e.g. QuickLook grinds my machine to halt even on 720p GIF), or resolutions below 100px.

sindresorhus commented 4 years ago

Maybe deduplicate them by percentages? (put in a hashmap using rounded percentage as the key)

They have different purposes. Someone might want exactly 25% of the original or someone might want an exact size.

The list could also use trimming: don't suggest HD resolutions (lots of GIF viewers are unprepared for that, e.g. QuickLook grinds my machine to halt even on 720p GIF), or resolutions below 100px.

That really depends on the FPS. I often use 960 for GIFs when there's little movement and low FPS.

jfeltesse commented 4 years ago

Sorry for the late reply.

Are there examples of the use case for wanting "exactly xx%"? I have no data alright, but I'd assume most, if not all, of the people primarily care about the size in pixels, and while having the % it corresponds to is very helpful, it doesn't drive the decision between multiple sizes.

If it's legit use case and the current layout ought to be kept, the one quick fix I can imagine is to add ~ to denote the % may not be exact (e.g. "800x450 (~20%)") but I'm not sure if it's universally recognized as meaning "approximately".

sindresorhus commented 4 years ago

Are there examples of the use case for wanting "exactly xx%"?

When you record on a retina screen (2x), you might want to scale to 50% exactly to get the same size as 1x.

I have no data alright, but I'd assume most, if not all, of the people primarily care about the size in pixels

You're assuming that everyone cares about the exact pixel size. That is rarely the case for me. I just want it smaller, and having some quick predefined "steps" are useful.

jfeltesse commented 4 years ago

It doesn't look like a simple solution is going to come off this issue so allow me to close it for now. I had opened this issue thinking it was some rounding bug but now I understand it's simply two different approaches.

Thanks for the tool and your other repos btw (using Ky on some projects)!

sindresorhus commented 4 years ago

We can keep it open until we figure out a solution.

janbrasna commented 3 years ago

I think the "(~##%)" approximation symbol works intuitively enough now. 👍

What might help to differentiate what's the primary value & what's secondary is: contrast, as in:

87270206-68fd5880-c50a-11ea-94f3-73f073fb26f4

… but i have no idea about such feasibility in Swift/UI.


PS: If you replace the "x" character with the correct "×" multiplication sign it helps the readability too. I've opened a PR #213 for it however I'm not 100% sure I can just slap such character in the String() format specifier 🤷‍♂️

sindresorhus commented 3 years ago

@janbrasna That's a good idea.

I'm also wondering if it would help if we aligned them as columns:

10 x 10    (4%)
100 x 100  (40%)