|Anonymous | Login||01-27-2020 20:59 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0002241||[Squeak] Morphic||minor||always||11-18-05 15:06||06-05-07 16:21|
|Summary||0002241: Translucent color lost when rotating a morph|
If you rotate a Morph with a translucent color like an EllipseMorph, the translucency is lost and a weird color appears. Strangely, this problem doesn't occur with a StarMorph.
It's seems that it is not a morphic bug, because the same bug exist with Tweak.
This is a very old bug. First apperance here in 2003 : http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-June/060660.html [^]
FormCanvas-transformByclippingToduringsmoothing.2.st [^] (1,785 bytes) 11-27-05 01:53
BitBltSimDocumentRuleTable.st [^] (3,909 bytes) 12-01-05 02:34
SYSTEM WARNING: Creating default object from empty value
SYSTEM WARNING: Creating default object from empty value
(0003117 - 1027 - 1063 - 1063 - 1063 - 1063 - 1063)
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)
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.
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)
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)
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.
(0003143 - 209 - 245 - 245 - 245 - 245 - 245)
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)
(0003144 - 144 - 156 - 156 - 156 - 156 - 156)
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)
|Well done Karl !|
(0003173 - 568 - 640 - 640 - 640 - 640 - 640)
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)
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.
(0003189 - 867 - 1163 - 1163 - 1163 - 1163 - 1163)
edited on: 01-22-06 08:39
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
alpha*srcColor+( (1-srcAlpha)*dstColor )
which was mutating the color.
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)
|Could we introduce this patch in 3.9 ?|
(0010759 - 161 - 161 - 161 - 161 - 161 - 161)
|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)
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 _ 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.
|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|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
127 total queries executed.|
65 unique queries executed.