From 20f99b62cf66c4794c6a5a73d34edbee77511413 Mon Sep 17 00:00:00 2001
From: John Cupitt <jcupitt@gmail.com>
Date: Thu, 2 Mar 2017 14:54:53 +0000
Subject: [PATCH] more ideas

---
 TODO                      | 26 ++++++++++++++++++++++++++
 libvips/resample/resize.c | 18 ++++++------------
 2 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/TODO b/TODO
index f4c7b471..b149f4e9 100644
--- a/TODO
+++ b/TODO
@@ -8,6 +8,32 @@
 	vips_rot( smartcrop->sobel, &smartcrop->sobel90, VIPS_ANGLE_D90, NULL )
 
 - vips linecache has access there twice!
+ 
+- resize.c has
+
+                need_lines = 1.2 * n_lines / vscale;
+
+  to size the line cache, and uses an unthreaded cache
+
+  	- is this formula right?
+	- instead put the cache inside shrinkv, on the output
+	- make shrinkv use threads to generate lines for input?
+
+  another alternative
+
+  	- add this caching to thumbnail.c
+	- remove the cache from resize
+	- don't use vips_resize(), expand code out
+	- put the cache just after shrinkv
+	- now there's no need to thread, since thumbnail is (mostly) just 
+	  doing image load on the input to shrink
+	- and we leave shink and resize nice and simple, though they will no
+	  longer work on seq files
+
+
+
+
+ -vips linecache has access there twice!
 
 	 $ vips linecache
 	 ...
diff --git a/libvips/resample/resize.c b/libvips/resample/resize.c
index 419717e5..3a70cf5f 100644
--- a/libvips/resample/resize.c
+++ b/libvips/resample/resize.c
@@ -206,17 +206,6 @@ vips_resize_build( VipsObject *object )
 	 * coming later, so read into a cache where tiles are scanlines, and 
 	 * make sure we keep enough scanlines.
 	 *
-	 * We use a threaded tilecache to avoid a deadlock: suppose thread1,
-	 * evaluating the top block of the output, is delayed, and thread2, 
-	 * evaluating the second block, gets here first (this can happen on 
-	 * a heavily-loaded system). 
-	 *
-	 * With an unthreaded tilecache, thread2 will get
-	 * the cache lock and start evaling the second block of the shrink. 
-	 * When it reaches the png reader it will stall until the first block 
-	 * has been used ... but it never will, since thread1 will block on 
-	 * this cache lock. 
-	 *
 	 * Cache sizing: we double-buffer writes, so threads can be up to one 
 	 * line of tiles behind. For example, one thread could be allocated
 	 * tile (0,0) and then stall, the whole write system won't stall until
@@ -226,6 +215,11 @@ vips_resize_build( VipsObject *object )
 	 * perhaps 0.5 or down as low as 0.3. So the number of scanlines we 
 	 * need to keep for the worst case is 2 * @tile_height / @residual, 
 	 * plus a little extra.
+	 *
+	 * Use an unthreaded tilecache to limit the range of Y values that an
+	 * image source has to span. Suppose we are shrinkv-ing by 100x and
+	 * need to span two tile rows on the output. Now the input source might
+	 * need to refer back 128 * 100 lines, argh. 
 	 */
 	if( int_vshrink > 1 ) { 
 		int tile_width;
@@ -241,7 +235,7 @@ vips_resize_build( VipsObject *object )
 			"tile_height", 10,
 			"max_tiles", 1 + need_lines / 10,
 			"access", VIPS_ACCESS_SEQUENTIAL,
-			"threaded", TRUE, 
+			"threaded", FALSE, 
 			NULL ) )
 			return( -1 );
 		in = t[6];