Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002296 [Squeak] Morphic minor always 12-06-05 18:14 10-15-06 08:25
Reporter wiz View Status public  
Assigned To
Priority normal Resolution open  
Status assigned   Product Version 3.9
Summary 0002296: What should happen if you set desktop color to translucent or transparent?
Description For this one.

Get a new project.
From the world menu get an appearance menu and make it stay up.
 From setDesktopColor swatch ( make it stay up too) request a translucent color.

Now pop up a world menu and dismiss it. Move the cursor.
Repeat.

For even more amusing results.
Now request a transparent desktop background.

repeat the same process.

Grab a star from the parts bin. Bring up its halo . Then grap it and move it around with all its halos still showing. Whee confetti.

Additional Information Is this a serious bug?

The example I gave is just an amusing consequece of pushing what squeak will do beyond what would reasonably be asked of it. Which is a good technique to use when exploring for bugs.

This points out a weakness of how colors are blended together when the destination also has an alpha component.

How squeak does alpha blending could use a rethink. There are several true uglinesses that need to be corrected anyway. Like what happens when a translucent rectange is rotated. See Mantis 0002241.

Fixing things so the display will not show ghosts even if set to a translucent or transparent background would be a good thing to include in any general fix of these graphics issues.

All is not where it should be yet.



Attached Files

- Relationships
related to 0003445closed tim In 3.9-7021 SMPackageLoader is initialized with a transparent gradient. This causes unexpected color changes. 

- Notes
(0003220 - 32 - 32 - 32 - 32 - 32 - 32)
andreas
12-07-05 01:22

All of these are Morphic issues.
 
(0003224 - 552 - 600 - 600 - 600 - 600 - 600)
wiz
12-08-05 05:19

Hi Andreas,

What combination rule provides a way to handle world morphs transparency correctly. s.t. we don't get the ghosting. How do you erase a morph on a transparent desktop. That was the graphic issue at the crux of my catagorization.

Either the method does not exist or it is obscure enough not to be obvious.

How to handle transparency correctly in general goes beyond morphic and affects the other schemes like tweak as well. If you have solved this problem in tweak please share or point me to where I can learn.

Cheers -wiz
 
(0003225 - 165 - 177 - 177 - 177 - 177 - 177)
andreas
12-08-05 07:20
edited on: 12-08-05 07:21

Just clearing the background with any constant color (black, white, zero whatever) will work. The reason you get ghosting is because the background is not cleared.

 
(0003254 - 2098 - 2212 - 2212 - 2212 - 2212 - 2212)
wiz
12-10-05 05:07

Ok. Thank you for the hint.

I know you are busy with your own agenda, So we'll consider this off your plate and to be solved as a morphic issue.

The rest is just to clear my mind an clarify the problem.

While what Andreas has suggested would surely do the trick it does not satisfy my sense of rightness or elegance. It suggests we would first have to check to see if the display under us was transparent or translucent and then clear it (or equally inelegantly clear it all the time.) Furturmore a form has no way to report if it is transparent and it decides translucency based on screen depth.

Finally the crux of the problem is this is the Display we are dealing with. It is a form but it is also the holder of the rendering of all forms. As the latter is not appropriate for it to also be translucent or transparent.

In particular transparency should be affected by what is beneath the transparent form but not what is above. And when rendered the resulting color represents something opaque.

So the display needs to represent the opaque rendering of transparent layers.
If it is itself filled with a transparent background color then that color needs to be rendererd with the default (virtual) background behind the display and the display itself becomes the opaque product of that rendering. The virtual background seems to be black is squeaks case.

Hmm. I wonder if just having display answer that it isOpaque would do the trick?

The problem is the persistence of the alpha in a form after it has been subject to a blending. This shows up also if you take an eye dropper to change a color. The color for say a rectangle still retains whatever alpha the rectangle started out with.

Finally somewhere in my head is that it would be fun an useful to have a way to have a separate form to represented just the alpha channel. PNG uses variable alpha transparency to do a more elegant anti-aliasing that looks good against any background. This notion is somewhat OT so I'll just mention it here and deal with it more directly some other time and in some other issue.
 
(0003255 - 1330 - 1400 - 1400 - 1400 - 1400 - 1400)
andreas
12-10-05 05:21

Uh, wiz (btw, who are you in real life?) thanks for letting me off the hook (not that I could've done anything anyway) but there are many things wrong with your argumentation, like:
- you are discussing this issue at too low a level (Form/Display) where you should be discussing it at the canvas level (Morphic does NOT deal with Display directly)
- your claim that "this is the display" may or may not be correct; rendering can happen to any form and in either case you'd have to clear the background.
- "as the latter is not appropriate for it to also be translucent or transparent" is again wrong: it depends on what that Display is composited with. In Croquet, for example, it makes perfect sense to have it be translucent/transparent.
- "If it is itself filled with a transparent background color then that color needs to be rendererd with the default (virtual) background behind the display and the display itself becomes the opaque product of that rendering. The virtual background seems to be black is squeaks case." No it isn't - that's my point. And because it isn't you get ghosting.
- "The problem is the persistence of the alpha in a form after it has been subject to a blending" That's not a problem; quite to the contrary. There are many things that can be done with an alpha channel, before or after blending.
 
(0003283 - 1321 - 1411 - 1411 - 1411 - 1411 - 1411)
wiz
12-12-05 03:05

Hi, Andreas,

(wiz = Jerome Peace, I'll write you my particulars later)

Thanks for your thinking.

The reason I am thinking about this at a low level is that my problem solving intuition tells me there is a problem at that level that if solved solves the rest. This could prove false, but when one is lost it is best to proceed until one is sure and then turn back.

My statement that the display is not like a normal form is because of its role as the canvas that people see. All the layers of forms or whatever that
are drawn on the canvas are eventually seen by the viewer as a whole. At which point what was transparent or translucent no longer matter.

The puzzle that puzzles me in this bug is why does it work (e.g. dismissing a menu and getting the screen back the way it was) when the display background is a solid color but not when it is transparent or translucent? Something interesting is going on here.

I do see your point about clearing a rendering form before it is drawn to. I haven't a clue yet as to where this should best occur. I presume there are lots of preformance issues riding on the choice.

In any event there is much you have presented here that is above my current understanding of squeak innards. Time to think some more and to come up with some concrete examples.
 
(0003286 - 1382 - 1542 - 1542 - 1542 - 1542 - 1542)
andreas
12-12-05 09:32

Some more notes:
- "At which point what was transparent or translucent no longer matter." Again, not true. It depends on the compositing performed with it.

- "The puzzle that puzzles me in this bug is why does it work (e.g. dismissing a menu and getting the screen back the way it was) when the display background is a solid color but not when it is transparent or translucent? Something interesting is going on here." Nothing really interesting, just that alpha blending uses the formula:

  dstColor := srcAlpha*srcColor + (1-srcAlpha)*dstColor

As you can see, dstColor is involved in the computation and therefore, unless either cleared (dstColor = 0) or opaque (srcAlpha = 1), you get a mix of the color used during this frame with the color used during the previous frame.

- "I do see your point about clearing a rendering form before it is drawn to. I haven't a clue yet as to where this should best occur. I presume there are lots of preformance issues riding on the choice." Probably not, clearing with a constant color is really cheap. The right place is (I think) WorldState>>drawWorld:submorphs:invalidAreasOn: where it says

  "Now paint from bottom to top, but using the reduced rectangles."
  rectToFill ifNotNil: [aWorld drawOn: (c := aCanvas copyClipRect: rectToFill)].

The rectToFill should be cleared if and only if aWorld has a translucent fill.
 
(0003312 - 2756 - 3057 - 3057 - 3057 - 3057 - 3057)
wiz
12-13-05 05:10

So more replies.

Andreas notes:

   Some more notes:
- "At which point what was transparent or translucent no longer matter." Again, not true. It depends on the compositing performed with it.

Wiz replies:

Your thinking from the point of veiw of the box which might want to do some more processing of the display. I'm thinking from the point of view of the observer who is just there to view the result. From that point of view no more compositing is taking place just viewing.

Andreas notes:

- "The puzzle that puzzles me in this bug is why does it work (e.g. dismissing a menu and getting the screen back the way it was) when the display background is a solid color but not when it is transparent or translucent? Something interesting is going on here." Nothing really interesting, just that alpha blending uses the formula:

  dstColor := srcAlpha*srcColor + (1-srcAlpha)*dstColor

As you can see, dstColor is involved in the computation and therefore, unless either cleared (dstColor = 0) or opaque (srcAlpha = 1), you get a mix of the color used during this frame with the color used during the previous frame.

Wiz replies:

Two things here. One the puzzle is with a translucent or transparent color for world erasing an opaque menu leaves the image of the menu on the display (or world form I'm not sure which) .
The srcAlpha is opaque the dstAlpha is translucent/transparent and the results are the puzzlement.

Wait. When the menu is erased the destination is overwritten with the world color which is translucent/transparent and the overwritten area is the display showing the image of the menu so....

OK, I knew there was something wrong with how the menu was being erased. And tada to erase it you have to fill the world color over something more neutral than the what the display image was showing (i.e the menu)
and my point that the virtual color behind the display is black (or white) and you have to start from there; and yours that you have to overwrite things with black or white become one and the same solution.

Andreas notes:

- "I do see your point about clearing a rendering form before it is drawn to. I haven't a clue yet as to where this should best occur. I presume there are lots of preformance issues riding on the choice." Probably not, clearing with a constant color is really cheap. The right place is (I think) WorldState>>drawWorld:submorphs:invalidAreasOn: where it says

  "Now paint from bottom to top, but using the reduced rectangles."
  rectToFill ifNotNil: [aWorld drawOn: (c := aCanvas copyClipRect: rectToFill)].

The rectToFill should be cleared if and only if aWorld has a translucent fill.

Wiz replies:

Cool that's then the place to start experimenting.
 

- Issue History
Date Modified Username Field Change
12-06-05 18:14 wiz New Issue
12-06-05 18:14 wiz Status new => assigned
12-06-05 18:14 wiz Assigned To  => andreas
12-07-05 01:22 andreas Note Added: 0003220
12-07-05 01:22 andreas Assigned To andreas =>
12-07-05 01:22 andreas Category Graphics => Morphic
12-08-05 05:19 wiz Note Added: 0003224
12-08-05 07:20 andreas Note Added: 0003225
12-08-05 07:21 andreas Note Edited: 0003225
12-10-05 05:07 wiz Note Added: 0003254
12-10-05 05:21 andreas Note Added: 0003255
12-12-05 03:05 wiz Note Added: 0003283
12-12-05 09:32 andreas Note Added: 0003286
12-13-05 05:10 wiz Note Added: 0003312
10-15-06 08:25 tim Relationship added related to 0003445


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