Anonymous | Login | 01-24-2021 22:52 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Advanced Details [ Jump to Notes ] | [ View Simple ] [ 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 | |||||||
Reporter | SergeStinckwich | View Status | public | |||||||||
Assigned To | ||||||||||||
Priority | normal | Resolution | open | Platform | ||||||||
Status | feedback | OS | ||||||||||
Projection | none | OS Version | ||||||||||
ETA | none | Fixed in Version | Product Version | 3.9 | ||||||||
Product Build | ||||||||||||
Summary | 0002241: Translucent color lost when rotating a morph | |||||||||||
Description |
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 [^] |
|||||||||||
Steps To Reproduce | ||||||||||||
Additional Information | ||||||||||||
Attached Files |
![]() ![]() |
|||||||||||
|
![]() |
||||||||||||||||
SYSTEM WARNING: Creating default object from empty value SYSTEM WARNING: Creating default object from empty value
|
![]() |
|
(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 alpha*srcColor+( (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. |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
127 total queries executed. 65 unique queries executed. |