I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger... So it's the best we can do, while keeping an efficient format. But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used. Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none. I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color. But did not change the rgb ComponentMax... Any reason why? If we encoded rgb component on 8 bits, and reverted the alpha channel encoding, then we could have colors pre-encoded on 32 bits, but most using only 24 bits (because most are opaque) would be represented as SmallInteger. But I don't know if it is really inter-operable, or more natural... Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats... Thoughts?
Nicolas Cellier wrote:
I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger... So it's the best we can do, while keeping an efficient format.
But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used. Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none.
I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color. But did not change the rgb ComponentMax... Any reason why?
If we encoded rgb component on 8 bits, and reverted the alpha channel encoding, then we could have colors pre-encoded on 32 bits, but most using only 24 bits (because most are opaque) would be represented as SmallInteger. But I don't know if it is really inter-operable, or more natural...
Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats...
Thoughts? Could 6 bits be enough for transparency? Perhaps only for Pharo's own system & UI stuff. Any bitmap editor application would probably need to extend to handle the full 8 bit alpha. Or maybe that adds unneeded complexity.
cheers -ben
2013/12/19 <btc@openinworld.com>
Nicolas Cellier wrote:
I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger... So it's the best we can do, while keeping an efficient format.
But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used. Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none.
I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color. But did not change the rgb ComponentMax... Any reason why?
If we encoded rgb component on 8 bits, and reverted the alpha channel encoding, then we could have colors pre-encoded on 32 bits, but most using only 24 bits (because most are opaque) would be represented as SmallInteger. But I don't know if it is really inter-operable, or more natural...
Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats...
Thoughts?
Could 6 bits be enough for transparency? Perhaps only for Pharo's own system & UI stuff. Any bitmap editor application would probably need to extend to handle the full 8 bit alpha. Or maybe that adds unneeded complexity.
cheers -ben
Yes, it would be sufficient, but it seems simpler to manage a separate 8 bit alpha channel as it is the case now.
Hello nicolas
I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger... So it's the best we can do, while keeping an efficient format.
But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used. Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none.
I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color. But did not change the rgb ComponentMax... Any reason why?
No special reason. We just started to clean the code to understand it and avoid isKindOf: and because we thought that there is no need to have color and translucent colors anymore.
If we encoded rgb component on 8 bits, and reverted the alpha channel encoding, then we could have colors pre-encoded on 32 bits, but most using only 24 bits (because most are opaque) would be represented as SmallInteger. But I don't know if it is really inter-operable, or more naturalâ¦
Thanks for the discussion. Now do you have an idea about the speed gain?
Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats...
Thoughts?
2013/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
Hello nicolas
I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger... So it's the best we can do, while keeping an efficient format.
But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used. Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none.
I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color. But did not change the rgb ComponentMax... Any reason why?
No special reason. We just started to clean the code to understand it and avoid isKindOf: and because we thought that there is no need to have color and translucent colors anymore.
If we encoded rgb component on 8 bits, and reverted the alpha channel encoding, then we could have colors pre-encoded on 32 bits, but most using only 24 bits (because most are opaque) would be represented as SmallInteger. But I don't know if it is really inter-operable, or more naturalâ¦
Thanks for the discussion. Now do you have an idea about the speed gain?
Absolutely no idea. BitBlt is rich enough (color maps or direct color components, depths, endianness) to make this unpredictable by simply analyzing sender chain in source code (it's too deep and convoluted). The best way is to try it, but then one must choose a benchmark, and here again it is a difficult decision, because maybe you didn't bench a path that some other use intensively, how to guess without above analysis? I saw those un-necessary mismatch while analyzing Graphics code... By a principle of economy, I suggest to remove them. Simplifying code a little bit is already a win. Then, les petits ruisseaux font les grandes rivières, cumulated micro optimizations may pay.
Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats...
Thoughts?
2013/12/25 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
2013/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
Hello nicolas
I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger... So it's the best we can do, while keeping an efficient format.
But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used. Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none.
I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color. But did not change the rgb ComponentMax... Any reason why?
No special reason. We just started to clean the code to understand it and avoid isKindOf: and because we thought that there is no need to have color and translucent colors anymore.
If we encoded rgb component on 8 bits, and reverted the alpha channel encoding, then we could have colors pre-encoded on 32 bits, but most using only 24 bits (because most are opaque) would be represented as SmallInteger. But I don't know if it is really inter-operable, or more naturalâ¦
Thanks for the discussion. Now do you have an idea about the speed gain?
Absolutely no idea. BitBlt is rich enough (color maps or direct color components, depths, endianness) to make this unpredictable by simply analyzing sender chain in source code (it's too deep and convoluted). The best way is to try it, but then one must choose a benchmark, and here again it is a difficult decision, because maybe you didn't bench a path that some other use intensively, how to guess without above analysis?
I saw those un-necessary mismatch while analyzing Graphics code... By a principle of economy, I suggest to remove them. Simplifying code a little bit is already a win.
BTW, did you see that scaled rgb components use 10bits while scaled alpha
uses 8? This was in Squeak already and has been perpetuated in Pharo refactoring... Then, les petits ruisseaux font les grandes rivières, cumulated micro
optimizations may pay.
Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats...
Thoughts?
Absolutely no idea. BitBlt is rich enough (color maps or direct color components, depths, endianness) to make this unpredictable by simply analyzing sender chain in source code (it's too deep and convoluted). The best way is to try it, but then one must choose a benchmark, and here again it is a difficult decision, because maybe you didn't bench a path that some other use intensively, how to guess without above analysis?
I saw those un-necessary mismatch while analyzing Graphics code... By a principle of economy, I suggest to remove them. Simplifying code a little bit is already a win.
BTW, did you see that scaled rgb components use 10bits while scaled alpha uses 8?
No :) because Iâm totally ignorant of this part and I need time to learn and Iâm too busy and too sick because I work too much.
This was in Squeak already and has been perpetuated in Pharo refactoring...
Thanks for the discussion. Now do you have an idea about the speed gain?
Absolutely no idea. BitBlt is rich enough (color maps or direct color components, depths, endianness) to make this unpredictable by simply analyzing sender chain in source code (it's too deep and convoluted). The best way is to try it, but then one must choose a benchmark, and here again it is a difficult decision, because maybe you didn't bench a path that some other use intensively, how to guess without above analysis?
I saw those un-necessary mismatch while analyzing Graphics code... By a principle of economy, I suggest to remove them. Simplifying code a little bit is already a win.
Then, les petits ruisseaux font les grandes rivières, cumulated micro optimizations may pay.
Ok yes We are doing that since years.
Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats...
Thoughts?
participants (3)
-
btc＠openinworld.com -
Nicolas Cellier -
Stéphane Ducasse