DamageRecorder>recordInvalidRect: one truncate too far?

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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DCBP: Detonate Chair on Bad Password

Does that change fix it?

Best,
Marcel

> On 30-01-2016, at 12:16 AM, marcel.taeumel <[hidden email]> 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; [hidden email]; 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

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

> On 01-02-2016, at 2:21 AM, marcel.taeumel <[hidden email]> 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; [hidden email]; 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

> On 02-02-2016, at 8:01 AM, marcel.taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CBA: Compare if Biorhythms Amenable

>> On 02-02-2016, at 8:01 AM, marcel.taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CMN: Convert to Mayan Numerals