Re: ext/gd: support creation of animated GIFs

From: Date: Mon, 09 Jan 2017 23:44:21 +0000
Subject: Re: ext/gd: support creation of animated GIFs
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-97650@lists.php.net to get a copy of this message
On 09.01.2017 at 21:19, Andrea Faulds wrote: > Christoph M. Becker wrote: > >> Kalle raised some objections regarding the direct use of streams in the >> API, namely that imagegifanimbegin() expects an open stream to be passed >> as parameter, so perhaps it would be better to accept a stream URL >> instead and manage the stream behind the scenes. That appears to be >> much more solid (as the developer couldn't fiddle with the stream), but >> would require some encapsulation mechanism, either a resource, what >> would be in line with the other GD resource types[4], or an (opaque) >> object, what appears more suitable for PHP 7. >> >> Currently, I'd prefer an *opaque* object which would be created by >> imagegifanimbegin() (creating the respective stream internally), passed >> to imageanimadd() and be destroyed by imagegifanimend(). > > Would this opaque object still allow you to use an arbitrary stream of > your choice? > > Also, like with imagepng() etc., could you stream the output to uh… > PHP's default output stream? (I'm not sure what it's called. The thing > that echo goes to.) It would be possible to allow either a stream URL or a stream to given, what would fit to image(png|jpeg|…)(). However, these are "stand-alone" functions which close the stream when they're finished, while the animated GIF writing functions would *allow* the stream to be manipulated by the userland developer, even though I can't see practical reason to do so. And, of course, we could also let the functions accept NULL to directly write to stdout. Passing in 'php://stdout' should have the same effect. > If it does both, I don't have much objection. > > Mind you… is it really necessary to hide the stream from the user? > fopen() is not particularly hard to use, and there are (admittedly > niche) cases where you might want to handle the stream yourself. Are there really such cases? Should we sacrifice the safety of internal stream handling to support some (hypothetical?) use cases? -- Christoph M. Becker

« previous php.internals (#97650) next »