Mantis Bugtracker
  

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
Reporter SergeStinckwich View Status public  
Assigned To
Priority normal Resolution open  
Status feedback   Product Version 3.9
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 [^]

Additional Information
Attached Files  FormCanvas-transformByclippingToduringsmoothing.2.st [^] (1,785 bytes) 11-27-05 01:53
 BitBltSimDocumentRuleTable.st [^] (3,909 bytes) 12-01-05 02:34

- Relationships

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

duplicate of 0001444closed  [BUG] TransformatinMorph and translucent colors 
parent of 0002344closed  Translucent color lost when rotating a morph 
has duplicate 0006519new  Rotating Round Rectangle affects its color 

- 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
 
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.
 

- 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


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
127 total queries executed.
65 unique queries executed.
Powered by Mantis Bugtracker