put the shrink line cache back

so we can use THINSTRIP for the vips_shrink() operation
This commit is contained in:
John Cupitt 2012-06-18 09:19:31 +01:00
parent f07fb25ab5
commit 7061f0f00b
2 changed files with 16 additions and 8 deletions

View File

@ -322,15 +322,12 @@ vips_shrink_build( VipsObject *object )
if( vips_image_copy_fields( resample->out, resample->in ) )
return( -1 );
/* We want to be able to work with sequential sources. THINSTRIP would
* be OK, but FATSTRIP would be a disaster: thread 2 would be given a
* strip some way down the output, which would be a huge distance down
* the input.
*
* Make sure we always work by insisting on SMALLTILE.
/* THINSTRIP will work, FATSTRIP will break seq mode. If you combine
* shrink with conv you'll need to use a line cache to maintain
* sequentiality.
*/
vips_demand_hint( resample->out,
VIPS_DEMAND_STYLE_SMALLTILE, resample->in, NULL );
VIPS_DEMAND_STYLE_THINSTRIP, resample->in, NULL );
/* Size output. Note: we round the output width down!
*/

View File

@ -162,8 +162,19 @@ shrink_factor( IMAGE *in, IMAGE *out,
}
/* Shrink!
*
* We want to make sure we read the image sequentially.
* However, the convolution we may be doing later will force us
* into SMALLTILE or maybe FATSTRIP mode and that will break
* sequentiallity.
*
* So ... read into a cache where tiles are scanlines, and make sure
* we keep enough scanlines to be able to serve a line of tiles.
*/
if( im_shrink( x, t[3], shrink, shrink ) ||
if( im_shrink( x, t[2], shrink, shrink ) ||
im_tile_cache( t[2], t[3],
t[2]->Xsize, 1,
VIPS__TILE_HEIGHT * 2 ) ||
im_affinei_all( t[3], t[4],
interp, residual, 0, 0, residual, 0, 0 ) )
return( -1 );