From 9209fb25c559c90bc257df226de602de5fe19083 Mon Sep 17 00:00:00 2001
From: John Cupitt <jcupitt@gmail.com>
Date: Thu, 10 Mar 2016 17:40:19 +0000
Subject: [PATCH] update notes

---
 ChangeLog | 5 ++---
 TODO      | 7 +------
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 8a9726f7..eb21cfe0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,6 @@
 29/1/16 started 8.3
-- add vips_reduce*() ... a fast path for bicubic downsize
-- vips_resize() and vips_similarity() use it when they can
+- add vips_reduce*() ... a fast path for affine downsize
+- vips_resize() uses vips_reduce() with lanczos3 and better anti-alias
 - bicubic is better on 32-bit int images
 - add pdfload, svgload, gifload for PDF, SVG and GIF rendering 
 - vipsthumbnail knows about pdfload and svgload
@@ -15,7 +15,6 @@
 - faster hist_find (Lovell Fuller)
 - webpload has a @shrink parameter for shrink-on-load
 - vipsthumbnail knows about webp shrink-on-load
-- more vips_resize() tuning, a bit quicker now
 - better behaviour for vips_cast() shift of non-int types (thanks apacheark)
 - python .bandrank() now works like .bandjoin()
 
diff --git a/TODO b/TODO
index 5f5b7803..5801f0f8 100644
--- a/TODO
+++ b/TODO
@@ -1,13 +1,8 @@
-- strange
-
-	john@kiwi:~/pics$ vips gaussblur babe.jpg x.v 0.2
-	gaussmat: mask too large
 
 - removed the cache from resize since we no longer sharpen, can we get
   out-of-order reads?
 
-- vips_resize() needs to take a param for kernel rather than interpolate?
-  maybe just don't expose this
+  seeeeeeems ok?
 
 - what demand hint are we setting for the reduce / shrink funcs?