vips_sequential() no longer bans all non-seq access, it just bans
rewinding --- if you ask for something some way ahead, it reads and
throws away pixels
this means VipsExtract and VipsInsert can now be seq: they will read and
throw away any stuff they don't need
the new vips base class was causing global balance to leak a bit
vips8 adds extra refs back though the pipeline -- this means that when
you make _local objects, they MUST be local to output. If they are local
to input, you'll get a ref cycle and a leak
the new sequential mode readers for tiff/jpg/png were not working well
from the vips7 command-line: they either decompressed twice, or handed
over a sequential mode image
it should now work as well as it did pre-seq.
the vips7 loaders were a thin layer over the new VipsForeign system
however! VipsForeign does various "useful" things, like open via disc,
and this resulted in stuff like
vips im_jpeg2vips huge.jpg x.v
decompressing to a temp file before copying to x.v
im_jpeg2vips() and friends now call the low-level loaders directly and
avoid the extra mechanisms in VipsForeign
"nip2 huge.jpg" was loading twice as well, for the same reason
cli operations turn on seq mode automatically when they can
vips_operation_get_flags() added: lets you attach a set of flags to an
operation
flags for now are "nocache" (replacing the old nocache system) and "seqential"
if vips_object_set_argument_from_string() from string sees "seq" flag on the
object for which it is setting the arg, it enables sequential mode
all operations which can run sequentially have been tagged
the operation printer knows about flags and can display them
lock around the operation cache and the upstrea/downstream link system
so vips works when used from many threads: you can now create an image
in one thread and process it in another
