Mantis - Squeak
Viewing Issue Advanced Details
2085 Morphic minor always 10-15-05 16:48 11-03-05 09:28
new 3.9  
0002085: [Bug] Different screen depths mess up project thumbnails.
For this one.

In a fresh 6693md5
Set the screen depth to 32
open a new project and enter it.
Put something in the project (I used a curve or triangle)
In the new project set the screen depth to 16.
Return to previous project.

The project view thumbnail is transparent.

Now change the screen depth in this project back to 16.
The thumbnail appears but the colors are modified (the white background was purple and the orange triangle was black)

Now open another new project. Put something in it like a triangle and return to previous project.

Everything in the new project has the correct thumbnail everything in the old project has the odd color thumbnail.

going into the old project and moving the curve and returning still leaves the thumbnail colors odd.

Well this is a repeatable way to get missing project thumbnails. I wonder whats going on.

10-15-05 19:01   
Two additional observations.

Using the system window corner grow handle will get the colors back to normal after the outer project has had its depth changed back to 16 from 32. (So the odd colors are probably confined to the last thumbnail and when that is forced to update we're back to normal. That leave the curiosity of why going into and then out of the inner project keeps the colors screwed up. The thumbnail clearly updates to show positional changes of the curve. Once the size has of the project view has changed and the colors are back to normal going in and out works fine too. A color translation cache sitting around somewhere?)

There is no problem with the thumbnails if the inner project is depth 32 and the outer is depth 16.
10-16-05 03:40   
This is a morphic issue not a "graphics" problem.
10-31-05 04:55   
Ha. More clues.

In 6690 using an image morph when I had a 32 bit form if the canvas (ie display was depth 16 the image appeared but if the depth was 32 the image dissappeared.

in 5976 (3.8aFrom3.0) the problem didn't appear.

ar 12/12/2001 01:09 drawing 88 implementors only in change set 4611BorderedImage

ImageMorph>>drawOn: aCanvas
    | style |
    (style _ self borderStyle) ifNotNil:[
        style frameRectangle: bounds on: aCanvas.
    self isOpaque
        ifTrue:[aCanvas drawImage: image at: self innerBounds origin]

        ifFalse:[aCanvas paintImage: image at: self innerBounds origin]

dgd 9/7/2004 17:24 drawing 63 senders 90 implementors no prior versions only in change set 6237ImageMorphTranslucentFix-dgd

ImageMorph>>drawOn: aCanvas
    | style |
    (style _ self borderStyle) ifNotNil:[
        style frameRectangle: bounds on: aCanvas.].
    self isOpaque
        ifTrue:[aCanvas drawImage: image at: self innerBounds origin]

        ifFalse:[aCanvas translucentImage: image at: self innerBounds origin]


ProjectViewMorph inherits from ImageMorph and calls super from its version of drawOn:.

Haloing in to PVM and using the red menu to set PVM to opaque will make the invisible project morph appear.

in 6690 following implementors of "aCanvas translucentImage: image at: self innerBounds origin" a couple of levels down...

We arrive at :

ar 2/10/2004 17:19

translucentImage: aForm at: aPoint sourceRect: sourceRect
    "Draw a translucent image using the best available way of representing translucency.
    Note: This will be fixed in the future."
    self shadowColor ifNotNil:[
        ^self stencil: aForm at: aPoint sourceRect: sourceRect color: self shadowColor].
    (self depth < 32 or:[aForm isTranslucent not])
        ifTrue:[^self paintImage: aForm at: aPoint sourceRect: sourceRect].

    self image: aForm
        at: aPoint
        sourceRect: sourceRect
        rule: Form blend

following this last method:

ar 5/14/2001 23:34 private

image: aForm at: aPoint sourceRect: sourceRect rule: rule
    "Draw the portion of the given Form defined by sourceRect at the given point using the given BitBlt combination rule."
    port colorMap: (aForm colormapIfNeededFor: form); fillColor: nil.
    port image: aForm at: aPoint + origin sourceRect: sourceRect rule: rule.

ar 2/17/2000 01:08

image: aForm at: aPoint sourceRect: sourceRect rule: rule
    "Draw the portion of the given Form defined by sourceRect at the given point using the given BitBlt combination rule."

    sourceForm _ aForm.
    combinationRule _ rule.
    self sourceRect: sourceRect.
    self destOrigin: aPoint.
    self copyBits

at this point I'm stumped i've see too many routines and can't pin point things down any closer.
One way to insure project tnails is to revert dgds drawOn routine back to ar's. But there is clearly an indication that not answering opaque causes problems too and this bug is only one symptom.

The facts in summary.

for PVMs 16 bit deep project show up invisible in 32 bit deep projects.
seting the PVM to opaque makes them visible but false colored.

For image morphs 32 bit forms show up invisible on 32 bit deep Displays. Marking the image morph opaque will restore visibility.
On 16 bit deep displays they are visible anyway.

The problem does not seem to happen in 3.7 (5976 and before). The dgd fix in 6237 probably had something to do with making the symptom appear.

11-02-05 06:08   
More to report.

I did some more poking around.

Form blend is defined as 24
This was originally ment for alphablending and in BitBlt alphablend demo is used for 32 bit source and destination.
It is the blend rule that causes the trouble. changing it to 25 (paint) will have things show up as we expect since it is paitimage that is called when the image morphs are marked opaque.

When I poked rule number 31 in instead of rule 24 I seemed to get a blending that worked. My image morphs didn't disappear and the transparent things seemed to show up correctly. (I also tried poking rule 30 and that caused transparent to be rendered as black.

the place I poked was Canvas>>translucentImage: aForm at: aPoint sourceRect: sourceRect

so that looked like the central crux of the issue.

graaagh gack. rule 31 doesn't solve the problem it doesn't preserve transparency. There are deeper problems here than I would like to contemplate.

This left a colormapping problem.
the tnail for a 16 bpp project will still be falsely colored in a 32 bpp project.

Ok. So its definitely the blend rule that renders the forms invisible. When and why not necessarily clear but changing the rule will change the bug.

So what is it suppose to be doing and what does it actually do?
11-03-05 03:52   
wiz - most likely the alpha channel of the form is broken; try to do a #fixAlpha on your invisible image morph and see if that helps. If it does, then the alpha channel got lost, most likely due to a 16->32bpp conversion.
11-03-05 09:28   
Hi Andreas,

imageMorph fixAlpha asMorph gave me the visible popup imageMorph. Thanks for your help. That saved me about a year of guessing.

fixAlpha could also be used on the project view morph and it would make it visible albeit with the false colors.

Of course with that "fixed" the popup thumbnails could be used to examine other things. I got a (tanslucent pink) round rectangle from objects and targeted it.

My popup image was translucent but not the same color. More grayish.

The most interesting thing was rotating the roundRectangle. With the rendering of the transformMorph the color becomes opaque. When I targeted the transformMorph I got a tilted rectangle but now the color was transparent again. (and grayish). Hmmm. This means it should be possible to find a fix that allows translucent rectanges to be rotated and retain their translucency.

I wonder what is causing the color itself to mutate. I wonder what can be done to keep it pure. I wonder if the smoothing sampling has something to do with this?