framebuffer: Make sure scaleBySize honors a DPI override #1258
Conversation
…t to the native DPI... As discussed in koreader/koreader#6977
Useful when switching from a custom DPI to the native one.
(As that's what front does)
|
Ref koreader/koreader#6977 (comment) So, we continue getting a different result whether auto 300 dpi vs. user-set 300 dpi ? |
|
Getting consistent results would involve just always going the scale_size + scale_dpi way (with scale_dpi actually being the scaleByDpi computation, i.e., dpi / 160), which would change a lot of things, yeah. At least this way it does what it probably intended to do without the weird corner-case of "except when override matches native". |
|
And this way, we can actually see what would happen if we went that route, by setting an override that matches our device's native DPI ;). |
|
At least on paper, it's definitely not a bad idea, and would probably not change much on legacy 600x800 devices, because scale_size is 1 there, and scaleByDpi would be almost exactly 1, too (167 / 160). |
|
OK, so not less puzzled :) |
…avior (#6984) * Make switching *back* to the default DPI via auto actually work properly. eg., by actually setting DPI back to defaults, and clearing the override flag. * Bump base to pickup koreader/koreader-base#1258
* Make sure scaleBySize *always* honors a DPI override, even if it's set to the native DPI... As discussed in koreader/koreader#6977 * Allow clearing a DPI override Useful when switching from a custom DPI to the native one. * Plug clearDPI into setDPI if it gets a nil (As that's what front does)
Even if said override happens to match the native DPI, because the scaleBySize heuristic is weird and results would differ.
c.f., koreader/koreader#6977 (comment)
This change is