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; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh as "Formating Drive C" appeared on the screen...
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; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh as "Formating Drive C" appeared on the screen...
On 05-12-2016, at 6:57 PM, Bob Arning arning315@comcast.net 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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Wasn't fully debugged before being released.
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 arning315@comcast.net 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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Wasn't fully debugged before being released.
On 06-12-2016, at 6:37 AM, Bob Arning arning315@comcast.net 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CPM: Change Programmer's Mind
squeak-dev@lists.squeakfoundation.org
-
Bob Arning -
tim Rowledge