This is good to hear. Rendering speed is important, especially if Gimp
wants to be a viable competitor to the mainstream counterparts, where
man-sized canvasses are concerned.
On 03/02/2011 03:18, Joao S. O. Bueno wrote:
On Wed, Feb 2, 2011 at 3:20 PM, Martin Nordholts<ense...@gmail.com> wrote:
On 02/02/2011 02:32 PM, Jeremy Nell wrote:
Will the next release of Gimp be a bit quicker?
I'm afraid not; the next release of GIMP, GIMP 2.8, will not be quicker
in this regard.
The release after that, GIMP 3.0, will focus on running on GTK 3.0 and
bringing high bit depths into the picture.
3.2 will focus on non-destructiveness
Maybe in 3.4 we'll have time to solve this in a proper way.
Actually, this may well be solved for GIMP 3.0 - as it will them most
depend on GEGL improvements.
Pippin has detailed the improvements that could be done on GEGL with
regards to speed rendering in a document he posted on Tuesday (I don't
remember if it was to this list):
mostly improvements that would allow the image viewport to be real
time rendered, while the real rendering would happen in background.
js
-><-
/ Martin
--
My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
