Morph corner radius set to 8 does surprising things

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Morph corner radius set to 8 does surprising things

timrowledge
In a plain Squeak 5.1 image, create a RectangleMorph and use its menu to set ‘round corners’.
Open the PreferenceBrowser and find the ‘Preferred Corner Radius’ - in the copy of the release 5.1-16548 I have that is ‘8’.

Now drag the rectangle morph - note how the corners get replaced by funny little filled triangles instead of being rounded!
Now change the preferred radius to 7. Note how the dragging works perfectly well. Try 9. Hell, try any other number.

So far as I can tell only 8 causes a problem. Clearly one answer is “don’t do that” and change the default. But I’m completely baffled as to what is going on here. Why only 8? Why only when being dragged? Right now I’m not able to spot where the drag rendering might diverge.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh as "Formating Drive C" appeared on the screen...



Reply | Threaded
Open this post in threaded view
|

Re: Morph corner radius set to 8 does surprising things

Bob Arning-2

This method in HandMorph seems to have a view of corner rounding that depends on a particular corner geometry. You might try changing the highlighted code to


            nPix := cacheCanvas form tallyPixelValues first.
            "--> begin rounded corners hack <---"
            cachedCanvasHasHoles := true "(nPix = 48 
                        and: [submorphs size = 1 and: [submorphs first wantsRoundedCorners]]) 
                            ifTrue: [false]
                            ifFalse: [nPix > 0]".
            "--> end rounded corners hack <---"

Some drawing of morphs in the hand may be slower, but on modern machines you might never notice it.

updateCacheCanvas: aCanvas 
    "Update the cached image of the morphs being held by this hand."

    "Note: The following is an attempt to quickly get out if there's no change"

    | subBnds rectList nPix |
    subBnds := Rectangle merging: (submorphs collect: [:m | m fullBounds]).
    rectList := damageRecorder invalidRectsFullBounds: subBnds.
    damageRecorder reset.
    (rectList isEmpty 
        and: [cacheCanvas notNil and: [cacheCanvas extent = subBnds extent]]) 
            ifTrue: [^self].

    "Always check for real translucency -- can't be cached in a form"
    self submorphsDo: 
            [:m | 
            m wantsToBeCachedByHand 
                ifFalse: 
                    [cacheCanvas := nil.
                    cachedCanvasHasHoles := true.
                    ^self]].
    (cacheCanvas isNil or: [cacheCanvas extent ~= subBnds extent]) 
        ifTrue: 
            [cacheCanvas := (aCanvas allocateForm: subBnds extent) getCanvas.
            cacheCanvas translateBy: subBnds origin negated
                during: [:tempCanvas | self drawSubmorphsOn: tempCanvas].
            self submorphsDo: 
                    [:m | 
                    (m areasRemainingToFill: subBnds) isEmpty 
                        ifTrue: [^cachedCanvasHasHoles := false]].
            nPix := cacheCanvas form tallyPixelValues first.
            "--> begin rounded corners hack <---"
            cachedCanvasHasHoles := (nPix = 48 
                        and: [submorphs size = 1 and: [submorphs first wantsRoundedCorners]]) 
                            ifTrue: [false]
                            ifFalse: [nPix > 0].
            "--> end rounded corners hack <---"
            ^self].

    "incrementally update the cache canvas"
    cacheCanvas translateBy: subBnds origin negated
        during: 
            [:cc | 
            rectList do: 
                    [:r | 
                    cc clipBy: r
                        during: 
                            [:c | 
                            c fillColor: Color transparent.
                            self drawSubmorphsOn: c]]]

On 12/5/16 8:47 PM, tim Rowledge wrote:
In a plain Squeak 5.1 image, create a RectangleMorph and use its menu to set ‘round corners’.
Open the PreferenceBrowser and find the ‘Preferred Corner Radius’ - in the copy of the release 5.1-16548 I have that is ‘8’.

Now drag the rectangle morph - note how the corners get replaced by funny little filled triangles instead of being rounded!
Now change the preferred radius to 7. Note how the dragging works perfectly well. Try 9. Hell, try any other number.

So far as I can tell only 8 causes a problem. Clearly one answer is “don’t do that” and change the default. But I’m completely baffled as to what is going on here. Why only 8? Why only when being dragged? Right now I’m not able to spot where the drag rendering might diverge.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh as "Formating Drive C" appeared on the screen...






Reply | Threaded
Open this post in threaded view
|

Re: Morph corner radius set to 8 does surprising things

timrowledge

> On 05-12-2016, at 6:57 PM, Bob Arning <[hidden email]> wrote:
>
> This method in HandMorph seems to have a view of corner rounding that depends on a particular corner geometry.

Thanks; that seems to be the responsible method. I’m quite at a loss to explain what was being thought of for the hack. Most … unusual.

> You might try changing the highlighted code to
>
>
>
>             nPix := cacheCanvas form tallyPixelValues first.
>             "--> begin rounded corners hack <---"
>             cachedCanvasHasHoles := true "(nPix = 48
>                         and: [submorphs size = 1 and: [submorphs first wantsRoundedCorners]])
>                             ifTrue: [false]
>                             ifFalse: [nPix > 0]".
>             "--> end rounded corners hack <—"

Instead of simply forcing cachedCanvasHasHoles to be true, it seems to work cleanly with
     cachedCanvasHasHoles := nPix >0.
which at least makes use of the tallyPixelValues first - which is quite a bit of work.



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Wasn't fully debugged before being released.



Reply | Threaded
Open this post in threaded view
|

Re: Morph corner radius set to 8 does surprising things

Bob Arning-2

It's not too unusual -- just old. There was, 15 years ago, some related code in HandMorph>>fullDrawOn: and your rounded-corner morph was correctly drawn, regardless of whether cachedCanvasHasHoles was set to true or false. Since that time, the drawing of rounded corners (and drop shadows as well, I guess) has changed a bit and now the value of cachedCanvasHasHoles does matter -- it needs to be true for rounded-corner things to draw correctly.


On 12/6/16 12:26 AM, tim Rowledge wrote:

      
On 05-12-2016, at 6:57 PM, Bob Arning [hidden email] wrote:

This method in HandMorph seems to have a view of corner rounding that depends on a particular corner geometry. 
Thanks; that seems to be the responsible method. I’m quite at a loss to explain what was being thought of for the hack. Most … unusual.

You might try changing the highlighted code to 



            nPix := cacheCanvas form tallyPixelValues first.
            "--> begin rounded corners hack <---"
            cachedCanvasHasHoles := true "(nPix = 48 
                        and: [submorphs size = 1 and: [submorphs first wantsRoundedCorners]]) 
                            ifTrue: [false]
                            ifFalse: [nPix > 0]".
            "--> end rounded corners hack <—"
Instead of simply forcing cachedCanvasHasHoles to be true, it seems to work cleanly with 
     cachedCanvasHasHoles := nPix >0.
which at least makes use of the tallyPixelValues first - which is quite a bit of work.



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Wasn't fully debugged before being released.






Reply | Threaded
Open this post in threaded view
|

Re: Morph corner radius set to 8 does surprising things

timrowledge

> On 06-12-2016, at 6:37 AM, Bob Arning <[hidden email]> wrote:
>
> It's not too unusual -- just old. There was, 15 years ago, some related code in HandMorph>>fullDrawOn: and your rounded-corner morph was correctly drawn, regardless of whether cachedCanvasHasHoles was set to true or false. Since that time, the drawing of rounded corners (and drop shadows as well, I guess) has changed a bit and now the value of cachedCanvasHasHoles does matter -- it needs to be true for rounded-corner things to draw correctly.

Thanks Bob. Oh the joys of software…

I’ll submit the modified version that appears to work and let’s see if it survives 15 years...


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CPM: Change Programmer's Mind