---------- Forwarded message ---------- From: Theodore Imre <blurymind@xxxxxxxxx> Date: Sun, Jul 27, 2008 at 9:56 PM Subject: Re: is watercolor (brush color blending mode)... To: Øyvind Kolås <pippin@xxxxxxxx> hi, as i am reading this, im getting more and more interested in the way gimp works and handles virtual and hd memory usage. I do not think that gimp should emulate real materials, and i do not consider a brush color blending dynamics - a watercolor emulation. As i read,gegl makes it possible to implement some very powerful features that are likely to make gimp grow a lot. I always thought that applications that have that blending brush dynamics dont actually store variables in each pixel on the screen (like paint quantity and thickness)- like painter or artrage. All such applications that i tried (sai,nekopaint,4thpaint) used a relatively low amount of virtual memory/cache space. So from what i read now, gimp cannot handle such a brush dynamics,because it is going to likely consume a lot of memory.How do these other applications manage to do it so lightly without much memory? Krita's color blending is not really what Souichi had started with his patch.From my observation that tool is trying to emulate real paints,and when one dips the brush over the colored parts of the canvas,it absorbs part of the color,altering the color inside the brush, and after you draw on a clean part,your color had changed. As beautiful as it is,the user doesnt have as much control over the color as in the simpler way-just color blending as in sai or especially 4thpaint- in 4thpaint the way it works visually seems simple- but there its variables,set differently on different bruses make it the ultimate blending tool- its so easy and enjoyable to get the right colors. Brushes with these dynamics are very powerful. Rotating the canvas is also a very usefull feature that is valuable when you draw with a tablet (you cannot rotate your tablet because hand-eye coordination is ruined,but rotating it on the screen makes it easier for one to get the right angles of lineart) Souichi > thank you for considering continuing your work on such an application, i really do hope you port/develop it to linux,because it is very much likely it will fulfill the big gap.If you do,i would love to try it,use it,tell everybody about it. It might take you a day or two to implement in gogh or mtpaint,but for thats because you have the power to do it,while most people like me,who just need it,its impossible.Mtpaint does not support layers,alpha channel or an eraser tool,would be cool if gogh had that feature.. But i really hope that Gimp doesnt just take design ideas from only photoshop and its tools and does not stick to photo manipulation only,while its foundations make it possible to grow in the right directions that make an artist use graphic software . A brush color blending mode would really make a big change and will make it a lot more enjoyable to use for drawing with a tablet.Gimp shouldnt really emulate real materials if it has that feature.. On Sun, Jul 27, 2008 at 8:38 PM, Øyvind Kolås <pippin@xxxxxxxx> wrote: > On Sun, Jul 27, 2008 at 7:34 PM, Souichi TAKASHIGE <sigetch@xxxxxxxxx> wrote: >> 2008/7/28 Liam R E Quin <liam@xxxxxxxxxxx>: >>> On Mon, 2008-07-28 at 01:19 +0900, Souichi TAKASHIGE wrote: >>>> [...] >>> >>>> But it costs too much memory when we >>>> make a lot of strokes -- and we *DO* make thousand of strokes when we >>>> draw an image -- compared to the current implementation which has a >>>> buffer per each layers. >>> >>> That's something that needs to be measured. >> >> I see. >> It takes much memory when we draw brushmarks many times on the same >> area, I think that is very usual situation. >> Perhaps we should study the memory usage for this situation. >> >>> Don't forget that right now, the strokes are stored individually in >>> the undo history anyway. >> >> Yes and no. GIMP copies previous tiles prior to its modification, but >> that is part of previous layer image, not a stroke itself. GIMP can >> forget the undo cache, and do forget the undo cache (on program >> termination for example.) >> On the other hand, GeglBuffers for each strokes should be kept >> persistently. That is a big difference between undo cache and contents >> of GeglBuffer. >> But we can estimate the rough memory usage for the situation above >> from the memory usage of the undo cache. > > The situation would be the same for GEGL once the bug in > http://bugzilla.gnome.org/show_bug.cgi?id=502465 gets resolved. Since > the part of the processing graph underneath the top most added stroke > doesn't change, and it can be recomputed from the parameters of the > nodes in the graph there is no need to always persist the actual > pixels. This is a general optimization that also will help other parts > of GEGL. Experimenting with the gegl-paint example in the GEGL sources > will be a natural thing to do when fixing this bug. (The code in there > should be easily modifiable to become full non-destructive again). > > /Øyvind K. > > -- > «The future is already here. It's just not very evenly distributed» > -- William Gibson > http://pippin.gimp.org/ http://ffii.org/ > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
