Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On 23 Feb, Nick Lamb wrote: Does this mean that you agree to ditching all the special code for the 3 and 1 byte case as well? I'd really love to see this changes although as already stated this might introduce a bit memory overhead in case the user didn't use the alpha channel at all. If we can get back COW during 1.3 this overhead is zero (all new channels / layers etc. can be created as COW tiles with the apppropriate contents -- huge speedup). COW is indeed a good thing. However I assume you address the mentioned memory overhead with your answer and I'm not sure how you would avoid it with copy-on-write. The 3 byte will be always problematic because we always step over memory boundaries which is a huge loss in performance on any modern architecture. However restructuring the code to have a special function for each of the possible cases could be a cure to the branchprediction smashing distinguish in the source of the performance critical functions. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On 22 Feb, Sven Neumann wrote: We'll face one problem if we decide to make alpha the default for all images: A lot of fileformats do not understand alpha and you actually don't want to save the alpha channel with the image at all if you never touched it. One way to solve this would be to introduce a function to check if the image's alpha channel is empty. This hint could be set from the already existing tile-row hints without too much overhead. As you said. For one we can use some special dirty flag for the Alpha channel and for the case of the non-alpha fileformats we simply do the same as now: Flatten image. Does this mean that you agree to ditching all the special code for the 3 and 1 byte case as well? I'd really love to see this changes although as already stated this might introduce a bit memory overhead in case the user didn't use the alpha channel at all. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
Zach, I know you're trying to make a point, but I'd actually agree with that assessment too, if for slightly different reasons. The user has no way of knowing what shade of gray they are about to place on the image. I don't think this is used anywhere near as commonly as layers/transparency, so isn't perceived as such a big problem. But it should get some attention as well. In this case, changing the toolbar when that image is active is a possibility, if grayscale editing is still a goal. Also, the color selectors would have to change depending on the mode, so you're introducing the same problem in a different spot. I think what it comes down to is that modes increase the load on the user of the tool. If they have to exist, there should always be a clear indicator of the current mode. Where possible, I'd like to see them go away. Seth If that is the case, I have noticed another flaw. When I am working in the grayscale image mode, and I use the paintbrush to try and draw a color on the image, it comes out in gray!! This is clearly wrong behavior. You would not expect a tool to have two different modes of operation depending on the image you are drawing on! Obviously, all images should be color. Zach -- [EMAIL PROTECTED] Zachary Beane http://www.xach.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
