Hi Folks,
I found a bug in BitBlt. The following rules: 20 rgbAdd:with: 21 rgbSub:with: 27 rgbMax:with 28 rgbMin:with: 29 rgbMinInvert:with: 37 rgbMul:with: will set alpha = 0 if the destination is 32 bit deep. This means that if the destination is 32bpp, these rules are useless, as they will ignore source and destination and always set all the pixels to transparent.
To test, try printing: f1 := Form extent: 8@8 depth: 32. f1 fillColor: (Color r: 1.0 g: 1.0 b: 0.7 alpha: 0.6). f2 := Form extent: 8@8 depth: 32. f2 fillColor: (Color r: 0.5 g: 1.0 b: 0.7 alpha: 0.7). bb :=(BitBlt toForm: f1) sourceForm: f2; combinationRule: 28; copyBits. (f1 colorAt: 2@2) alpha
The fix I propose is in the last line of all those methods, to change 'nBits: 8 nPartitions: 3' to read 'nBits: 8 nPartitions: 4'. This would make all these operations to treat alpha as they treat red, green and blue. This could have some performance impact. Reasonable alternatives includes leaving alpha unchanged, set it to 255 (opaque), or set it to (source max: destination).
What do you think?
Thanks, Juan Vuletich
What do you think?
Yes, this looks like the right thing to do.
Cheers, - Andreas
Juan Vuletich wrote:
Hi Folks,
I found a bug in BitBlt. The following rules: 20 rgbAdd:with: 21 rgbSub:with: 27 rgbMax:with 28 rgbMin:with: 29 rgbMinInvert:with: 37 rgbMul:with: will set alpha = 0 if the destination is 32 bit deep. This means that if the destination is 32bpp, these rules are useless, as they will ignore source and destination and always set all the pixels to transparent.
To test, try printing: f1 := Form extent: 8@8 depth: 32. f1 fillColor: (Color r: 1.0 g: 1.0 b: 0.7 alpha: 0.6). f2 := Form extent: 8@8 depth: 32. f2 fillColor: (Color r: 0.5 g: 1.0 b: 0.7 alpha: 0.7). bb :=(BitBlt toForm: f1) sourceForm: f2; combinationRule: 28; copyBits. (f1 colorAt: 2@2) alpha
The fix I propose is in the last line of all those methods, to change 'nBits: 8 nPartitions: 3' to read 'nBits: 8 nPartitions: 4'. This would make all these operations to treat alpha as they treat red, green and blue. This could have some performance impact. Reasonable alternatives includes leaving alpha unchanged, set it to 255 (opaque), or set it to (source max: destination).
What do you think?
Thanks, Juan Vuletich
Andreas Raab wrote:
What do you think?
Yes, this looks like the right thing to do.
Cheers,
- Andreas
Thanks, Andreas.
Can you advice on the steps for this fix to get into the precompiled VMs? This is my first contribution to the VM since the end of the SqC days...
BTW, it looks like BitBlt rule 41 (for subpixel rendering) was never incorporated into precompiled VMs. Why?
Thanks, Juan Vuletich
Juan Vuletich wrote:
Can you advice on the steps for this fix to get into the precompiled VMs? This is my first contribution to the VM since the end of the SqC days...
Get it into VMMaker and then lobby for an update. David has been the front-man for integration lately so you might want to ping him.
BTW, it looks like BitBlt rule 41 (for subpixel rendering) was never incorporated into precompiled VMs. Why?
No idea.
Cheers, - Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
Can you advice on the steps for this fix to get into the precompiled VMs? This is my first contribution to the VM since the end of the SqC days...
Get it into VMMaker and then lobby for an update. David has been the front-man for integration lately so you might want to ping him.
Let's try. Tim are you there? You're the maintainer of VMMaker right?
BTW, it looks like BitBlt rule 41 (for subpixel rendering) was never incorporated into precompiled VMs. Why?
No idea.
Cheers,
- Andreas
Does anybody know?
Cheers, Juan Vuletich
On Tue, Mar 31, 2009 at 04:14:36PM -0300, Juan Vuletich wrote:
Andreas Raab wrote:
Juan Vuletich wrote:
Can you advice on the steps for this fix to get into the precompiled VMs? This is my first contribution to the VM since the end of the SqC days...
Get it into VMMaker and then lobby for an update. David has been the front-man for integration lately so you might want to ping him.
Let's try. Tim are you there? You're the maintainer of VMMaker right?
Juan,
I'm helping out in Tim's (hopefully temporary) absence. If you can send a change set to this list, I'll add it to VMMaker on SqueakSource. If you can also open a Mantis issue to keep a record of the issue, that would be even better. There is a "VM" bug category on Mantis (bugs.squeak.org) for things like this.
Thanks,
Dave
David T. Lewis wrote:
Juan,
I'm helping out in Tim's (hopefully temporary) absence. If you can send a change set to this list, I'll add it to VMMaker on SqueakSource. If you can also open a Mantis issue to keep a record of the issue, that would be even better. There is a "VM" bug category on Mantis (bugs.squeak.org) for things like this.
Thanks,
Dave
Hi David,
I added #7327 to Mantis, and I attached the fix too.
Thanks, Juan Vuletich
On Wed, Apr 01, 2009 at 09:12:15AM -0300, Juan Vuletich wrote:
I added #7327 to Mantis, and I attached the fix too.
Thanks Juan,
I will pull this into VMMaker as soon as I can. I'm having some internet/ISP problems at the moment so it may take me a day or so until I can reconnect with SqueakSource et al.
Dave
David T. Lewis wrote:
On Wed, Apr 01, 2009 at 09:12:15AM -0300, Juan Vuletich wrote:
I added #7327 to Mantis, and I attached the fix too.
Thanks Juan,
I will pull this into VMMaker as soon as I can. I'm having some internet/ISP problems at the moment so it may take me a day or so until I can reconnect with SqueakSource et al.
Dave
Thanks David!
Cheers, Juan Vuletich
On Thu, Apr 02, 2009 at 10:03:46AM -0300, Juan Vuletich wrote:
David T. Lewis wrote:
On Wed, Apr 01, 2009 at 09:12:15AM -0300, Juan Vuletich wrote:
I added #7327 to Mantis, and I attached the fix too.
Thanks Juan,
I will pull this into VMMaker as soon as I can. I'm having some internet/ISP problems at the moment so it may take me a day or so until I can reconnect with SqueakSource et al.
Dave
Thanks David!
This is in VMMaker-dtl.119 on SqueakSource. I set Mantis #7327 status to "resolved".
Juan, just for the record, can you please confirm that your contributions to VMMaker are released under MIT license? ...just in case somebody starts asking about it five years from now ;)
Thanks a lot,
Dave
David T. Lewis wrote:
On Thu, Apr 02, 2009 at 10:03:46AM -0300, Juan Vuletich wrote:
David T. Lewis wrote:
On Wed, Apr 01, 2009 at 09:12:15AM -0300, Juan Vuletich wrote:
I added #7327 to Mantis, and I attached the fix too.
Thanks Juan,
I will pull this into VMMaker as soon as I can. I'm having some internet/ISP problems at the moment so it may take me a day or so until I can reconnect with SqueakSource et al.
Dave
Thanks David!
This is in VMMaker-dtl.119 on SqueakSource. I set Mantis #7327 status to "resolved".
Juan, just for the record, can you please confirm that your contributions to VMMaker are released under MIT license? ...just in case somebody starts asking about it five years from now ;)
Thanks a lot,
Dave
I signed the Viewpoints agreement. I believe it covers both past and future contributions. If not, this is my statement:
All my contributions to VMMaker and the rest of Squeak, both past and future, are (or will be) released under the MIT license.
HTH, Juan Vuletich
At Thu, 02 Apr 2009 10:22:00 -0300, Juan Vuletich wrote:
Juan, just for the record, can you please confirm that your contributions to VMMaker are released under MIT license? ...just in case somebody starts asking about it five years from now ;)
Thanks a lot,
Dave
I signed the Viewpoints agreement. I believe it covers both past and future contributions. If not, this is my statement:
All my contributions to VMMaker and the rest of Squeak, both past and future, are (or will be) released under the MIT license.
The Viewpoints agreement covers the past contribution made under the Squeak License, but a clear statement like this (and perhaps a clearer one on your website) would be good.
-- Yoshiki
Yoshiki Ohshima wrote:
At Thu, 02 Apr 2009 10:22:00 -0300, Juan Vuletich wrote:
Juan, just for the record, can you please confirm that your contributions to VMMaker are released under MIT license? ...just in case somebody starts asking about it five years from now ;)
Thanks a lot,
Dave
I signed the Viewpoints agreement. I believe it covers both past and future contributions. If not, this is my statement:
All my contributions to VMMaker and the rest of Squeak, both past and future, are (or will be) released under the MIT license.
The Viewpoints agreement covers the past contribution made under the Squeak License, but a clear statement like this (and perhaps a clearer one on your website) would be good.
-- Yoshiki
Why "would be good" and not "is good"? What is missing?
The Cuis image (the most significant code I published since I signed the agreement) is under the MIT license (thanks to you Yoshiki!). It includes a workspace with a clear statement.
I will include a general statement in my site covering any code found there.
Is there anything else you believe I should do?
Thanks, Juan Vuletich
Juan Vuletich wrote:
Why "would be good" and not "is good"? What is missing?
Figure of speech I think.
The Cuis image (the most significant code I published since I signed the agreement) is under the MIT license (thanks to you Yoshiki!). It includes a workspace with a clear statement.
I will include a general statement in my site covering any code found there.
Is there anything else you believe I should do?
Just being clear and consistent about it is a good thing.
Cheers, - Andreas
At Mon, 06 Apr 2009 22:20:35 -0300, Juan Vuletich wrote:
The Viewpoints agreement covers the past contribution made under the Squeak License, but a clear statement like this (and perhaps a clearer one on your website) would be good.
-- Yoshiki
Why "would be good" and not "is good"? What is missing?
The Cuis image (the most significant code I published since I signed the agreement) is under the MIT license (thanks to you Yoshiki!). It includes a workspace with a clear statement.
Sorry for writing an obscure message. What I meant was more about a blurb on your website.
I will include a general statement in my site covering any code found there.
Is there anything else you believe I should do?
That should be enough. I downloaded a version played with it but now cannot tell a license file was in the .zip file or not. It is good to have it in there, too.
-- Yoshiki
Yoshiki Ohshima wrote:
At Mon, 06 Apr 2009 22:20:35 -0300, Juan Vuletich wrote:
The Viewpoints agreement covers the past contribution made under the Squeak License, but a clear statement like this (and perhaps a clearer one on your website) would be good.
-- Yoshiki
Why "would be good" and not "is good"? What is missing?
The Cuis image (the most significant code I published since I signed the agreement) is under the MIT license (thanks to you Yoshiki!). It includes a workspace with a clear statement.
Sorry for writing an obscure message. What I meant was more about a blurb on your website.
I will include a general statement in my site covering any code found there.
Is there anything else you believe I should do?
That should be enough. I downloaded a version played with it but now cannot tell a license file was in the .zip file or not. It is good to have it in there, too.
-- Yoshiki
Thanks for the clarification. BTW, I did not include a license file in Cuis (but I could do it!). I included a workspace with a statement inside the image. Is that ok?
Cheers, Juan Vuletich
At Tue, 07 Apr 2009 11:50:49 -0300, Juan Vuletich wrote:
Thanks for the clarification. BTW, I did not include a license file in Cuis (but I could do it!). I included a workspace with a statement inside the image. Is that ok?
I am not a lawyer thing here. My inner gut says that the workspace is actually ok... But by interpreting some other people's past opinions, there are some merit for both so having it at both places is better nonetheless and can serve different purposes. So, if you don't mind, just save the content of workspace to a file and include it, and have it on the website as well.
Etoys ended up with taking the on-disk license file as "master" and upon the release build process, load it and keep it in the image as well. But this is just really a precautional measure and was not essential.
-- Yoshiki
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Juan Vuletich -
Yoshiki Ohshima