Comment 5 for bug 1467740

So, here is some history of this. The old thumbnailer, when presented with (-1,-1), delivered a 512 thumbnail. That wasn't really by design, but a side-effect of how the code was written. When we changed to the new thumbnailer, we decided to return the full-size image for an invalid QSize.

That turned out to be a mistake: when we ran a bunch of apps and scopes against the new thumbnailer, we found that there were lots of cases were the caller passed an uninitialized QSize, and we returned a full-size image in response. To the caller, everything appears to be working correctly, but it's working horribly inefficiently, both in terms of disk space and in terms of scaling.

If the caller wants a full-size image, it can do that, by asking for (0, 0). The advantage is that asking for a full-size image becomes an explicit operation, so it won't happen by accident.

I don't quite understand why you need to know the aspect ratio beforehand. Surely, there must be some display size into which the thumbnail is expected to fit? If we get something like QSize(512, 0) or (0, 512), we assume a 512x512 bounding box and scale accordingly. (We always preserve aspect ratio.) So, why not use that? And, if you really want a full-size image, just ask for (0,0) and you'll get it. But we can't return a full-size image for an uninitialized QSize; all that does is hide errors and it causes things to run horribly inefficiently.

Returning some other size for (-1,-1) will be wrong most of the time for most callers, no matter what size we pick. It'll be too small and look bad, or it'll be too large and inefficient.