more ideas
This commit is contained in:
parent
1046619f3a
commit
20f99b62cf
26
TODO
26
TODO
|
@ -7,6 +7,32 @@
|
||||||
|
|
||||||
vips_rot( smartcrop->sobel, &smartcrop->sobel90, VIPS_ANGLE_D90, NULL )
|
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 has access there twice!
|
||||||
|
|
||||||
$ vips linecache
|
$ vips linecache
|
||||||
|
|
|
@ -206,17 +206,6 @@ vips_resize_build( VipsObject *object )
|
||||||
* coming later, so read into a cache where tiles are scanlines, and
|
* coming later, so read into a cache where tiles are scanlines, and
|
||||||
* make sure we keep enough scanlines.
|
* 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
|
* Cache sizing: we double-buffer writes, so threads can be up to one
|
||||||
* line of tiles behind. For example, one thread could be allocated
|
* 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
|
* 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
|
* 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,
|
* need to keep for the worst case is 2 * @tile_height / @residual,
|
||||||
* plus a little extra.
|
* 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 ) {
|
if( int_vshrink > 1 ) {
|
||||||
int tile_width;
|
int tile_width;
|
||||||
|
@ -241,7 +235,7 @@ vips_resize_build( VipsObject *object )
|
||||||
"tile_height", 10,
|
"tile_height", 10,
|
||||||
"max_tiles", 1 + need_lines / 10,
|
"max_tiles", 1 + need_lines / 10,
|
||||||
"access", VIPS_ACCESS_SEQUENTIAL,
|
"access", VIPS_ACCESS_SEQUENTIAL,
|
||||||
"threaded", TRUE,
|
"threaded", FALSE,
|
||||||
NULL ) )
|
NULL ) )
|
||||||
return( -1 );
|
return( -1 );
|
||||||
in = t[6];
|
in = t[6];
|
||||||
|
|
Loading…
Reference in New Issue