That's great, thanks Michael. I'll remove my patch and update from your repo.
On Mon, 5 Apr 2021 at 14:51, Michael Drake <michael.dr...@codethink.co.uk> wrote: > > Hi John, > > Thanks for the patch. It is an improvement and I've applied it. > I'm currently considering moving the call to gif_initialise_sprite > into gif_decode_frame so that the bitmap area is always created > when a client calls gif_decode_frame. At the moment it will only > happen for the first frame that is to be displayed, which is a > change in behavior. > > I've fixed decode_gif.c to consult the display flag. > > By the way, your patch had tabs for indent, but that file > (inexplicably) uses spaces. I changed the patch to use > spaces to match but I plan to convert the whole file to > tabs soon. > > Best regards, > Michael > > > On 03/04/2021 12:33, jcup...@gmail.com wrote: > > Here's a better version of the patch: > > > > https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch > > > > (removes a stray create_bitmap call) > > > > > > On Fri, 2 Apr 2021 at 11:58, <jcup...@gmail.com> wrote: > >> > >> Hi all, > >> > >> I had a thought regarding memory allocation in libnsgif. > >> > >> At the moment, calling `gif_initialise()` will parse the GIF file and > >> allocate memory for rendering. You then call gif_decode_frame() to > >> decompress and render each frame of the animation. > >> > >> However, this means just opening the GIF can trigger very large memory > >> allocations, with no chance for the caller to intervene, except by > >> putting a hard pixel limit into the bitmap_create() callback. For > >> example, a 20 byte GIF can cause a 17gb malloc. > >> > >> How about delaying the allocation of the bitmap until the first call > >> to gif_decode_frame()? This would allow the caller to check the > >> detected width and height and apply some kind of size policy before > >> allowing rendering to occur. > >> > >> Here's a possible patch that does this. It's very simple and does not > >> affect the API, just the memory behaviour (I think): > >> > >> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a > >> > >> John > > _______________________________________________ > > netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org > > To unsubscribe send an email to netsurf-dev-le...@netsurf-browser.org > > > > -- > Michael Drake https://www.codethink.co.uk/ _______________________________________________ netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org To unsubscribe send an email to netsurf-dev-le...@netsurf-browser.org
