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>
To allow us to create previews of files stored in appdata we need to
construct the view differently.
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>
- implement isAvailable
- run tests only if ImageMagick with HEIC support is available in the
environment
Signed-off-by: Sebastian Steinmetz <me@sebastiansteinmetz.ch>
Exporting all pages of a document to a PDF is a waste of time. All we
need is a thumbnail of the first page anyway. Plus, reading that PDF
(even just the first page of it) into imagick is presumably much
slower than reading a simple PNG.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Fixes#9469
When a version of a file is restored the previews are no longer valid.
Thus we should remove them so they are regenerated.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This code had the potential to time out. If a huge folder with pictures
for example was deleted then this could easily grow the number of files
to clean with a factor 5 (or more).
Now the previews just get cleaned up in the background. Which is good
enough for the 99% case
As a bonus this now also keeps the previews when in the trashbin so you
don't have a spiking server load when a user opens the trashbin view.
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>
* Fixes#2739
It tries to create an image from an SVG file. Which we don't support. So
this fails and prints an log line. Then we fall back anyways to the 404
and fetch the default icon.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The owner of a federated file is the federated user. For which we
obviously can't setup a view.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
