The main use case here is storage provided versioning where we dont have
separate file ids for all the versions, by allowing a prefix for the
version we can store separate previews for all the versions.
Additionally, by keeping all the version previews in the same folder as the
"normal" previews they will be cleaned up properly when the file is deleted
Signed-off-by: Robin Appelman <robin@icewind.nl>
the main difference is passing the `File` object to the provider
instead of a `View` + path
Old providers will still continue to work as before
Signed-off-by: Robin Appelman <robin@icewind.nl>
Before we'd round up all preview request to their nearest power of two.
This resulted still in a lot of possible images. Generating a lot of
server load and taking up a lot of space.
This moves it to previews to be powers of 4: 64, 256, 1024 and 4096
Also the first two powers are always skipped (4, 16) as it doesn't make
sense to generate previews for that.
We cache preview pretty agressively and I feel this is a better
tradeoff.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Else if a preview provider is registerd but not available (for example
missing support in some external lib). It will do 💥. This way the
providers can at least do the sanity checks required.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* delete it
* throw a NotFound Exception
- This should a proper 404 to the user
- Next time it is then regenerated
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* IImage::crop/preciseResize now have type hinting for integers
* found while testing strict typing for PHP 7+
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
With HiDPI screens. And even normal HD screens you want more detail from
your pictures. Or the ability to somewhat zoom on you previews. For this
we need somewhat larger previews.
Moving the default to 4096x4096 is a step up. Users that want the old
behavior can still set the values in config.php
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Throw proper exception if we can't get the mimetype for a preview. Catch
it later on so we can just return a not found for the preview.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
For legacy reasons we stored all the previews with a png extention.
However we did not put png data in them all the time.
This caused the preview endpoints to always report that a preview is a
png file. Which was a lie.
Since we abstract away from the storage etc in the previewmanager. There
is no need anymore to store them as .png files and instead we can use
the actual file extention.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If you request a preview of X by Y. And after calculating X and Y are
equal to maxWidth and maxHeight then there is no reason to create a
preview of that size.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
