small experiment

TODO

@@ -1,31 +1,3 @@
-- if we do 
-
-	vips_region_prepare( VipsRect { 0, 0, 100, 10 } )
-	vips_region_prepare( VipsRect { 0, 1, 100, 10 } )
-
-  do we recalculate the whole region, or shift the calculated bits down and
-  just fetch another line?
-
-  how would we calculate a small part of a region?
-
-  vips_region_fill() would need to do this
-
-  instrument a bit and see what kinds of buffers we are seeing
-
-  if we see 
-
-	buffer.done: true
-	buffer.area: {0, 0, 100, 10 }
-
-  and we are asked for 
-
-	buffer.area: {0, 1, 100, 10 }
-
-  we can scroll, then use vips_region_prepare_to() to calculate just the 
-  new pixels ... would this fix it?
-
-
-
 - try SEQ_UNBUFFERED on jpg source, get out of order error?
 
 - could load pdf thumbnails?

libvips/iofuncs/region.c

@@ -886,6 +886,15 @@ vips_region_fill( VipsRegion *reg, VipsRect *r, VipsRegionFillFn fn, void *a )
 	g_assert( reg->im->dtype == VIPS_IMAGE_PARTIAL );
 	g_assert( reg->im->generate_fn );
 
+	/* You'd think we could check reg and see if it already has some of 
+	 * the pixels we need. If it does, we could copy them and only
+	 * generate the new ones. 
+	 *
+	 * However, we usually have neighboring regions on different threads,
+	 * so from the point of view of this thread, we will get no overlaps
+	 * on successive prepare requests. 
+	 */
+
 	/* Should have local memory.
 	 */
 	if( vips_region_buffer( reg, r ) )

libvips/resample/reduceh.cpp

@@ -285,6 +285,10 @@ reduceh_notab( VipsReduceh *reduceh,
 	}
 }
 
+/* Tried a vector path (see reducev) but it was slower. The vectors for
+ * horizontal reduce are just too small to get a useful speedup.
+ */
+
 static int
 vips_reduceh_gen( VipsRegion *out_region, void *seq, 
 	void *a, void *b, gboolean *stop )