README adjustments:

[qscale] / README

diff --git a/README b/README
index bcccb86ca0e35f5c16971f7430591fac655cc2e1..98b88c3f406aba47113484f73520ebdf7cd11d41 100644 (file)
--- a/README
+++ b/README
@@ -18,8 +18,8 @@ capable of doing much more than qscale can ever hope to do. Comparison between
 the two are mainly to provide a well-known reference, and to demonstrate that
 more specific tools than usually be made faster than generic tools.
 
-qscale is not novel in any way, nor is it perfect (far from it; it's more of a
-proof of concept than anything else) -- it is mainly a piece of engineering.
+qscale is not novel in any way, nor is it perfect (far from it; it's more like
+a proof of concept) -- it is mainly a piece of engineering.
 However, the following techniques deserve some kind of mention:
 
  - qscale recognizes that JPEGs are usually stored in the YCbCr colorspace and
@@ -37,9 +37,8 @@ However, the following techniques deserve some kind of mention:
  - qscale can utilize the SSE instruction set found in almost all modern
    x86-compatible processors to do more work in the same amount of instructions
    (It can also use the SSE3 instruction set, although the extra boost on top
-   of SSE is smaller. In time, it will utilize the SSE extensions known as
-   SSE4.1, which can help even more.) It takes care to align the image data and
-   memory accesses on the right boundaries wherever it makes sense.
+   of SSE is smaller.) It takes care to align the image data and memory
+   accesses on the right boundaries wherever it makes sense.
  - qscale recognizes (like almost any decent scaling program) that most
    practical filter kernels are separable, so scaling can be done in two
    sequential simpler passes (horizontal and vertical) instead of one. The
@@ -80,6 +79,16 @@ The following optimizations are possible but not done (yet?):
    on 64-bit x86-compatible (usually called amd64 or x86-64) machines. In
    fact, out of the box it might not even compile on such machines.
 
+Finally, a word of advice: Even the fastest scaler can never be as fast as not
+scaling. If you can do less work, or move it to a time where it is less user
+visible, do that no matter how you scale your pictures. In particular, cache
+your downscaled pictures if you can, preferrably ahead of time. If you cannot
+predict in advance exactly what size (or sizes) you'll need, consider making
+mipmaps (ie. one image of half the resolution each way, another one of a quarter
+the resolution each way etc., down to a reasonable size) and scaling from them
+instead. It will be much faster (primarily due to less loading time) and the
+difference in quality is nearly impossible to detect, at least in my tests.
+
 qscale is Copyright 2008 Steinar H. Gunderson <sgunderson@bigfoot.com>, and
 licensed under the GNU General Public License, version 2. The full text of
 the GPLv2 can be found in the included COPYING file.