0002241: Translucent color lost when rotating a morph

Notes
(0003117 - 1027 - 1063 - 1063 - 1063 - 1063 - 1063) KenCausey 11-18-05 20:08 edited on: 11-19-05 23:54	I've confirmed this quickly in 3.9a-6704. Let me note that just because Tweak exhibits the same or similar bug that does not mean that this is not a bug in Morphic. It's entirely possible that Tweak replicates the same logic error. I can't at the moment figure out why this would be at a lower level than Morphic. But in any case I think it would be best for the Morphic team to investigate the cause of this and if they decide that in fact it does not reside with Morphic then they will probably have a much better idea than your or me as to where the problem resides. Note that choosing a category is always a 'best guess' thing. Please always make a choice. The choice steers the issue to the team (in theory) and hopefully your guess is at least good enough that they will have some perspective on the issue and even if it is not there direct responsibility they may fix it and forward the fix to the appropriate people or perhaps more likely simply recategorize the issue so it goes to the appropriate people.

(0003120 - 1083 - 1203 - 1203 - 1414 - 1414 - 1414) wiz 11-19-05 07:30	Hi Serge, Glad to see this bug on mantis. The transparency loss is due to the Transform morph. StarMorphs are polygons and polygons rotate w/o using Transform morphs thus they do not have the problem. See also: Mantis 0002085: [Bug] Different screen depths mess up transparency... Mantis 0001800: [Fix] Manifying a color form would change its colors. for some more clues. A good help towards a solution would be to document bitblt. Rules past 32 or so don't even have hints as to what they do in any comments. And you can't even trust the commented ones until they are tested. To get an idea of the variety of undocumented rules browse the senders of combinationRule: . A good useful project / exersize would be to make lots of bitblt examples showing the results of various inputs. Varing the inputs enough to document what the rules do. I don't think we can rely on the original implementers for documentation but the squeak box knows. All we have to do is ask it nicely and it will explain. If you do this post pictures of the results here.

(0003141 - 228 - 240 - 450 - 450 - 450 - 450) SergeStinckwich 11-26-05 22:23	Karl Remberg send a patch to correct this problem : http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/098273.html [^] In 3.9a-6704, when you rotate the morph remains now translucent but the color still changes.

(0003142 - 146 - 176 - 176 - 176 - 176 - 176) KarlRamberg 11-27-05 00:57	I added a check to see if the form depth is 32 bits. So use the file uploaded last. Colors still change a little on a rotated ellipse. karl

(0003143 - 209 - 245 - 245 - 245 - 245 - 245) KarlRamberg 11-27-05 01:57	Ok, I found the right combination rule: 34 ! Everything works nice now exept under less than 32 bit depth, but that is another story/bug/feature :-) (I deleted all prior file versions of the fix) Karl

(0003144 - 144 - 156 - 156 - 156 - 156 - 156) wiz 11-27-05 04:40	Great work Karl, I tried out the fix in 3.9 and it is so nice to see the tilted morphs with the correct colors. Thanks for your persistence.

(0003145 - 16 - 16 - 16 - 16 - 16 - 16) SergeStinckwich 11-27-05 16:40	Well done Karl !

(0003173 - 568 - 640 - 640 - 640 - 640 - 640) wiz 11-30-05 07:14 edited on: 11-30-05 07:17	I've noticed at least one more place that rule 34 should replace a Form Blend rule: Canvas>>translucentImage: aForm at: aPoint sourceRect: sourceRect The other uses of Form blend probably need to be checked and decided about as well. Also can we find rule 34 a name and add it to form class so it can used just like Form over etc. I noticed also that rule 34 gave some interesting translucent results at depth 16. So I am wondering if there would be a way to supply it with an appropriate color map to get it to behave usefully at depths less than 32?

(0003174 - 446 - 506 - 506 - 506 - 506 - 506) KarlRamberg 11-30-05 19:40	If you install VMMaker you will get the plugin code. Take a look at BitBltSimulation>>tryCopyingBitsQuickly wich look like it does some of the delegation to conversion between different bit depths. Conversion lokks like it happens in alphaSourceBlendBits32, alphaSourceBlendBits16, alphaSourceBlendBits8 Combination rule 34 is called alphaBlendScaled:with: It looks like most stuff is implemented, it just needs the right hooks. Karl

(0003189 - 867 - 1163 - 1163 - 1163 - 1163 - 1163) wiz 12-01-05 02:33 edited on: 01-22-06 08:39	Hi Karl I got a chance to look (a little) into the vmMaker code. (Squeak3.8-6665Full had it pre-loaded.) When I looked at the alphaBlendScaled routine the comment explained why it worked better then the blend rule. "Blend sourceWord with destinationWord using the alpha value from sourceWord. Alpha is encoded as 0 meaning 0.0, and 255 meaning 1.0. In contrast to alphaBlend:with: the color produced is srcColor + (1-srcAlpha) * dstColor e.g., it is assumed that the source color is already scaled. the unscaled blend uses alphasrcColor+( (1-srcAlpha)dstColor ) which was mutating the color. I've uploaded: BitBltSimDocumentRuleTable.st which is the initializing routine augmented with the comments from the methods where I could find them. I just commented the later ones figuring the earlier we well enough known.

(0004861 - 38 - 38 - 38 - 38 - 38 - 38) SergeStinckwich 05-04-06 19:54	Could we introduce this patch in 3.9 ?

(0010759 - 161 - 161 - 161 - 161 - 161 - 161) kks 05-31-07 09:11	FWIW, I tried the fix on 3.8-05 (Squeakland), 3.9 and 3.10. The fix works fine on the last two but not on Squeakland image (with latest updates from the server).

(0010774 - 456 - 516 - 550 - 550 - 550 - 550) kks 06-05-07 16:21	The fix results in a faint blue (rgb=0.968,1,1) patch for display depths 32 (but not for 16-bit) when RectangleMorph or EllipseMorph (not StarMorph or CurveMorph) are rotated. My xserver depth is 16-bits. Steps to duplicate on 3.10alpha7105 or 3.9 1. File in the fixes 2. Set display depth to 32 \|r\| r _ RectangleMorph new position: 200@100. /> r openInWorld. r heading: 30. The blue patch pops up. If the display depth is set to 16, it goes away.

Issue History
Date Modified	Username	Field	Change
11-18-05 15:06	SergeStinckwich	New Issue
11-18-05 15:06	SergeStinckwich	Status	new => assigned
11-18-05 15:06	SergeStinckwich	Assigned To	=> KenCausey
11-18-05 20:04	KenCausey	Assigned To	KenCausey =>
11-18-05 20:04	KenCausey	Status	assigned => new
11-18-05 20:04	KenCausey	Category	Any => Morphic
11-18-05 20:08	KenCausey	Note Added: 0003117
11-19-05 07:30	wiz	Note Added: 0003120
11-19-05 23:54	KenCausey	Note Edited: 0003117
11-19-05 23:54	KenCausey	Relationship added	duplicate of 0001444
11-26-05 22:19	SergeStinckwich	File Added: FormCanvas-transformByclippingToduringsmoothing.st
11-26-05 22:23	SergeStinckwich	Note Added: 0003141
11-27-05 00:51	KarlRamberg	File Added: FormCanvas-transformByclippingToduringsmoothing.1.st
11-27-05 00:57	KarlRamberg	Note Added: 0003142
11-27-05 00:57	KarlRamberg	Status	new => feedback
11-27-05 01:53	KarlRamberg	File Deleted: FormCanvas-transformByclippingToduringsmoothing.st
11-27-05 01:53	KarlRamberg	File Deleted: FormCanvas-transformByclippingToduringsmoothing.1.st
11-27-05 01:53	KarlRamberg	File Added: FormCanvas-transformByclippingToduringsmoothing.2.st
11-27-05 01:57	KarlRamberg	Note Added: 0003143
11-27-05 04:40	wiz	Note Added: 0003144
11-27-05 16:40	SergeStinckwich	Note Added: 0003145
11-30-05 07:14	wiz	Note Added: 0003173
11-30-05 07:17	wiz	Note Edited: 0003173
11-30-05 19:40	KarlRamberg	Note Added: 0003174
12-01-05 02:33	wiz	Note Added: 0003189
12-01-05 02:34	wiz	File Added: BitBltSimDocumentRuleTable.st
12-10-05 15:45	KarlRamberg	Issue cloned	0002344
12-10-05 15:45	KarlRamberg	Relationship added	parent of 0002344
01-22-06 08:39	wiz	Note Edited: 0003189
05-04-06 19:54	SergeStinckwich	Note Added: 0004861
05-30-07 23:58	wiz	Relationship added	has duplicate 0006519
05-31-07 09:11	kks	Note Added: 0010759
06-05-07 16:21	kks	Note Added: 0010774