Bug? in SkiaControl.Shared.AdaptCachedLayout is doubling Left/Top offsets. TBD under what circumstances.

[ToolmakerSteve]

I believe I have surfaced a latent problem in AdaptCachedLayout.
I need to determine exactly what in my layout of SkiaControls causes this.

This is when scrolling SkiaScroll. It has become a problem because on one path through DrawnUI code, the doubling occurs, BUT on a different path, the doubling does not occur. As a result, my content draws in one of two different positions (offsets), depending on ...[I'll add a comment when I know more]...

What I see so far:

• AdaptCachedLayout is called for my custom SkiaLayout, which is Content of a SkiaScroll.
• AdaptCachedLayout is called with destination that has Left, Top offsets.
• ArrangedDestination ALSO has those offsets!
• These lines result in the DOUBLED offsets:

var newDestination = ArrangedDestination;//.Clone();
newDestination.Offset(destination.Left, destination.Top);

---

Example:

+	destination	{{Left=-52,Top=-1,Width=∞,Height=∞}}	SkiaSharp.SKRect
+	ArrangedDestination	{{Left=-52,Top=-1,Width=∞,Height=∞}}	SkiaSharp.SKRect
=> `Destination` setter called with:
+	value	{{Left=-104,Top=-2,Width=∞,Height=∞}}	SkiaSharp.SKRect

---

Workaround:

I override AdaptCachedLayout to remove newDestination.Offset(...); line.

---

UPDATE

Given workaround, no longer have "doubled" values.
BUT my control is still drawn in two different positions, when it has been scrolled.

Now instead of "correct offset" and "doubled offset", the two positions are:
"zero offset", as if Scroll = (0,0), and "correct offset".
Investigating.

[ToolmakerSteve]

This code path gives correct offsets, for controls inside SkiaScroll:

This code path gives doubled offsets:

[taublast]

Thanks, Steve! Sorry for slow reaction, sick these days, will get in ranks soon.

[taublast]

I believe I have surfaced a latent problem in AdaptCachedLayout. I need to determine exactly what in my layout of SkiaControls causes this.

This is when scrolling SkiaScroll. It has become a problem because on one path through DrawnUI code, the doubling occurs, BUT on a different path, the doubling does not occur. As a result, my content draws in one of two different positions (offsets), depending on ...[I'll add a comment when I know more]...

What I see so far:

• AdaptCachedLayout is called for my custom SkiaLayout, which is Content of a SkiaScroll.
• AdaptCachedLayout is called with destination that has Left, Top offsets.
• ArrangedDestination ALSO has those offsets!
• These lines result in the DOUBLED offsets:

var newDestination = ArrangedDestination;//.Clone();
newDestination.Offset(destination.Left, destination.Top);

Example:

+	destination	{{Left=-52,Top=-1,Width=∞,Height=∞}}	SkiaSharp.SKRect
+	ArrangedDestination	{{Left=-52,Top=-1,Width=∞,Height=∞}}	SkiaSharp.SKRect
=> `Destination` setter called with:
+	value	{{Left=-104,Top=-2,Width=∞,Height=∞}}	SkiaSharp.SKRect

Workaround:

I override AdaptCachedLayout to remove newDestination.Offset(...); line.

UPDATE

Given workaround, no longer have "doubled" values. BUT my control is still drawn in two different positions, when it has been scrolled.

Now instead of "correct offset" and "doubled offset", the two positions are: "zero offset", as if Scroll = (0,0), and "correct offset". Investigating.

I think I know where this might come from.
Is it possible you changed the measuring process for your custom scroll or for the content wrapper (hopefully a skialayout)? What type is your content actually?

[taublast]

One thing to know is that we land inside Arrange either when the parent measures us, either for "self-measure" that happens for top views on the canvas AND occasionally for any view when it's marked as dirty but for reason it's redrawing BEFORE the parent had the luck to measure it as due.

[taublast]

Failing to reproduce :/ Would need to see your custom SkiaLayout specifics that are causing this.

[taublast]

Related to #102, at first approach reproducible with parent container not taking full canvas width and children centered.

[taublast]

Must be resolved with #105