Form>asFormOfDepth: appears to break transparency

> I have Form of 16bpp, which results from rotating a ColorForm with  
> WarpBlt. This 16bpp form displays ‘properly’ when painted onto  
> another form such as the Display. So far so good.
>
> If I run it through my Scratch filters (which do fun things like  
> colour warping, whirling and pixellating) it all goes horribly  
> wrong; the once transparent areas are now solid black instead. This  
> makes me very sad :-(
>
> The culprit appears to be #asFormOfDepth: and in particular the  
> recently added (ok, 2008 vintage) fiddle to stuff 16rFF into the top  
> byte of each pixel. I kinda see the logic of this newfangled bit  
> poking but suspect that it needs to be done a touch more cleverly  
> and should avoid pixels where transparency is expected. Or maybe the  
> bitblt code for paint needs some futzing?
>
> Anybody feeling familiar with this stuff and able to explain it a bit more?
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Sentio aliquos togatos contra me conspirare =  
> I think some people in togas are plotting against me.

> On 11-10-2014, at 5:00 AM, J. Vuletich (mail lists)  
> <[hidden email]> wrote:
>>
>> What do you get if you evaluate:
>>
>> f _ Form extent: 8@8 depth: 16.
>> f32 _ f asFormOfDepth: 32.
>> {f colorAt: 1@1. f32 colorAt: 1@1 }
>>
>> If you get transparent twice, then the problem is not in  
>> #formOfDepth:, but in your Scratch filters... If that is the case,  
>> an alternative to fixing them to support 16bpp would be to do all  
>> the stuff in 32bpp.
>
> I get transparent in both cases, but
> a) this is done *before* the scratch filtering in order to make  
> 32bpp forms because the plugin code to do swirlies etc only handles  
> 32bpp. (I’d love to alter this; a move to using 16bpp everywhere in  
> Scratch would benefit the Pi greatly since it is frequently memory  
> bus bound)
> b) inspect the two bitmaps; you’ll see that the 8bpp one has 0s but  
> the 32bpp has 16rFF000000s.
> c) display each of them with ‘paint’ and you’ll notice that the  
> 32bpp one is black and the 8bpp one is invisible
>
> |f f32|
> f := Form extent: 8@8 depth: 16.
> f32 := f asFormOfDepth: 32.
> f displayOn: Display at: 500@10 rule: Form paint.
> f32 displayOn: Display at: 510@10 rule: Form paint.
> {f . f32 }
>
> Inspect that to see what I mean.
>
> If I use a hacked asFormOfDepth: that does not do the alpha channel  
> ‘fixing’ then both Forms are transparent. This doesn’t surprise me  
> much since that is what asFormOfDepth: did in Squeak in the ancient  
> days when Scratch was first written by scraping tiny symbols on  
> polished stone slabs.
>
>>
>> Can you prepare an image for us to try? It would help us give  
>> better answers.
>
> No need, since this is not stuff I’ve changed (At least.. not  
> knowingly. Always a chance I’ve screwed something up somewhere, of  
> course)
> However, the image is available from  
> https://github.com/raspberrypi/scratch/blob/master/NuScratchBeta10.tgz in a  
> package which includes the Pi vm etc. Just shift-click on the top  
> half of the ‘R’ in the Scratch logo and ‘turn fill screen off’ to  
> get to the desktop.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Romani quidem artem amatoriam invenerunt. =  
> You know, the Romans invented the art of love.

> Yes. In Squeak there is a bug in #asFormOfDepth: . The last lines are:
>
> "Special case: For a 16 -> 32 bit conversion fill the alpha channel because it gets lost in translation."
> (self depth = 16 and:[d= 32]) ifTrue:[newForm fillAlpha: 255].
>
> But they should be as in Cuis:
>
> "If we build a 32bpp from one of smaller depth,
> it will have zero in the alpha channel (until BitBlt is fixed!)"
> d = 32 ifTrue: [
> newForm fixAlpha ].
>
> I think this should fix your problem.

> On 11-10-2014, at 12:23 PM, J. Vuletich (mail lists)  
> <[hidden email]> wrote:
>> Yes. In Squeak there is a bug in #asFormOfDepth: . The last lines are:
>>
>> "Special case: For a 16 -> 32 bit conversion fill the alpha  
>> channel because it gets lost in translation."
>> (self depth = 16 and:[d= 32]) ifTrue:[newForm fillAlpha: 255].
>>
>> But they should be as in Cuis:
>>
>> "If we build a 32bpp from one of smaller depth,
>> it will have zero in the alpha channel (until BitBlt is fixed!)"
>> d = 32 ifTrue: [
>> newForm fixAlpha ].
>>
>> I think this should fix your problem.
>
> Yup. Given that there is a bitblt rule specifically to fix this  
> problem, and a method specifically provided to use said bitblt to  
> specifically fix this problem, I’m more than a bit puzzled as to why  
> the most important bit of code (to be specific) in the image that  
> needs this specific bit of code, doesn’t, specifically, have it.  
> Even weirder is that Andreas wrote it and five years later carefully  
> rewrote asFormOfDepth: to deal with this problem *and didn’t use his  
> own careful fix*.

>>
>> Besides, the sample code I sent gets transparent, although the  
>> stuff in the Form, 16rFF000000, is opaque black. This is because of  
>> another bug, this one at #colorFromPixelValue:depth: . I suggest  
>> taking the code verbatim from Cuis.
>
> Probably a good idea.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- Can't find log base two of 65536 without a calculator.