I’m having *all sorts* of fun working on a TransformationMorph with optimised displaying of stuff scaled ½, 1 or 2X.
One of the common irritations is occasional invalid rectangle misses so that gribblys are left on-screen. There are assorted places where i see an ‘expandBy: 1’ apparently thrown in to try to compensate for something. I think perhaps the issue is actually in DamageRecorder>recordInvalidRect: where we see several places with code like 'origin truncated corner: corner truncated’ and maybe, just maybe, it ought to be ‘origin truncated corner: corner ceiling’ ?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
Does that change fix it?
Best, Marcel
-- View this message in context: http://forum.world.st/DamageRecorder-recordInvalidRect-one-truncate-too-far-... Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 30-01-2016, at 12:16 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Does that change fix it?
No idea yet; stuck in the bowels of transform morphs and scaling bitmaps as efficiently as possible for special cases etcetc. Makes your head spin (or stretch, depending upon the transform).
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Experience is something you don't get until just after you need it.
You're right. #truncated is wrong here. We need #ceiling and #floor calls. We have to fix that. Additionally, I wonder whether the magic numbers 40, 4, and 15 still hold for modern systems/VMs.
Best, Marcel
-- View this message in context: http://forum.world.st/DamageRecorder-recordInvalidRect-one-truncate-too-far-... Sent from the Squeak - Dev mailing list archive at Nabble.com.
There are other calls of #truncated to rectangles, where IMO #expanded is needed. And there is #truncated in #transformBy:clippingTo:#during:#smoothing in FormCanvas where one really should decide for #ceiling OR #floor to avoid shrinking thinks by accident.
Best, Marcel
-- View this message in context: http://forum.world.st/DamageRecorder-recordInvalidRect-one-truncate-too-far-... Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 01-02-2016, at 2:21 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
There are other calls of #truncated to rectangles, where IMO #expanded is needed.
Ah, I’d forgotten about #expanded. Should be perfect.
And there is #truncated in #transformBy:clippingTo:#during:#smoothing in FormCanvas where one really should decide for #ceiling OR #floor to avoid shrinking thinks by accident.
I suspect there are many places needing attention. I am glad somebody else sees the issue, makes me more confident of the likely solution.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The substance "Hey Y'all, watch this!" is known by the state of California to be hazardous to your health.
Only 184 calling methods to check. :-)
Best, Marcel
-- View this message in context: http://forum.world.st/DamageRecorder-recordInvalidRect-one-truncate-too-far-... Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 02-02-2016, at 8:01 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Only 184 calling methods to check. :-)
If only I had a bunch of enthusiastic young students to unleash on the problem.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CBA: Compare if Biorhythms Amenable
On 02-02-2016, at 8:01 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Only 184 calling methods to check. :-)
I find myself suspicious about TransformMorph>invalidRect:from: since it has an expandBy:1 that I can’t help thinking was an attempt to trigger later code to round the corners co-ordinates. If scale were fractional then we’d likely get ‘4.5’ type results and so I could imagine someone doing an expandBy:1 to try to end up with ‘4’ instead. #expanded has the extra virtue of keeping us to integer points.
After some futzing around with Scratch code it is clear that when scaling by 2X that the expandBy: is causing the system to display the damage area 1 pixel too far down. Replacing the expandBy: with expanded works much better, so I think we can accept it as an improvement. Scaling by ½ still works nicely as well.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CMN: Convert to Mayan Numerals
squeak-dev@lists.squeakfoundation.org
-
marcel.taeumel -
tim Rowledge