Thumbnail ioslave can now receive a devicePixelRatio metadata parameter, that it will pass to its thumbnail creators plugins implementing ThumbCreatorV3.
It updates the directory thumbnail generation.
Port image, jpeg, djvu, krita, svg, text to new ThumbCreatorV3.
Depends on D29397
Manualy tested
With dolphin D29525
| No Linters Available |
| No Unit Test Coverage |
| Buildable 26597 | |
| Build 26615: arc lint + arc unit |
You do seem to calculate the deviceWidth and height an awful lot, it makes reading a bit clunky. I'd much rather have the multiplication done once and then always use the var instead. In fact, perhaps it'd make sense to have createV3 feed the values into the implementations? Currently they all repate the same two lines over and over.
| thumbnail/djvucreator.cpp | ||
|---|---|---|
| 61 | Surely multiplication results need converting to int. That being said, you do multiply below again, so maybe just move maxWidth/Height up here. | |
| thumbnail/thumbnail.cpp | ||
| 774 | Var naming is a bit inconsistent across the code base now. In the implementations there are maxWidth/H that are device-adjusted but in here they are not. Not a huge concern, just noticed. | |
I just sent a specification evolution to cover this use case : https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/35
| thumbnail/imagecreator.cpp | ||
|---|---|---|
| 48 | This whole hunk should not be part of this submission. Also, the comment ("jpeg") is likely wrong. | |
Yes and that's up to thumbnail creators to decide. To take advantage of this, we would need to introduce some ThumbnailCreator type that would say whether or not generated thumbnail might be influenced by DPR (i.e) text. That would necessitate change the ThumbnailCreator API.
But the implementation will stay a lot simpler if we don't this level of complexity and adding will have a limited interest. Storing twice large@1 would happen only when a user would change DPR, thumbnails cache size limit will stay enforced.
No, just add a "DisplayPixelRatioDependent=true" key to the service data of the thumbnailer.
But the implementation will stay a lot simpler if we don't this level of complexity and adding will have a limited interest. Storing twice large@1 would happen only when a user would change DPR, thumbnails cache size limit will stay enforced.
You are changing every single thumbnailer implementation, although the results are binary identical for normal@2 and large@1. And that are only the thumbnailers in kio-extra.
And on top of all this, the only thumbnailer which is DPR dependent (text) does not even cache the data on disk.