Windowscommunitytoolkit: Hard to read text while editing a textbox in the InfiniteCanvas control

[michael-hawker]

Describe the bug

Editing text in the InfiniteCanvas appears to have some overlay making it hard to read the text, see the screenshot below.

• [ ] Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to InfiniteCanvas sample in sample app
2. Add a textbox
3. Start typing
4. Notice that there's some white text overlaid making it hard to read as you type, if you click out and stop editing, it goes away.

Expected behavior

Able to read text while editing without white overlay.

Screenshots

Environment

NuGet Package(s): 

Package Version(s): 

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [x] Insider Build (build number: 19592)

App min and target version:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] Insider Build (xxxxx)

Device form factor:
- [ ] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio 
- [ ] 2017 (version: )
- [ ] 2019 (version: ) 
- [ ] 2019 Preview (version: )

Additional context

Again not sure if this is just happening on Insider build, but noticed it in both Store version and local dev version of Sample App.

If this is a regression, I'm not sure of the last version it worked.

[Kyaa-dost]

@michael-hawker I have tried this multiple times in different theme settings, sizes, font styles, and I am still not able to reproduce this bug. Wondering how it showed up as overlaid text for you 🤔

[deanchalk]

I’ve been working in this area of the code today on another related issue. Would be happy to try and get to the bottom of it if you assign to me - thanks

[Kyaa-dost]

@deanchalk are you able to reproduce this?

[deanchalk]

@deanchalk are you able to reproduce this?

I think I know how to, will try and get to the bottom of it

[deanchalk]

@Kyaa-dost - I tried, but simply couldn't reproduce this issue, either with the store app or debugging the code

[salmanmkc]

Working on this

[michael-hawker]

Figured out that this is specific to running the app in dark theme. In light theme it appears to work correctly.

[michael-hawker]

@deanchalk I took a stab at this now that I knew the underlying issue, see comment here...

Thoughts on maybe trying to restructure how this control works?

[deanchalk]

I'll take another look at this over the weekend

[michael-hawker]

@deanchalk and/or @salmanmkc were you still interested in taking another look at this? I think the underlying issue here is that we're trying to both render on the canvas directly and have the text box above.

I think when in 'Edit' mode we should just be using the TextBox itself, and when we're done switch back to the rendered version? I think this would make it more reliable without having to deal with it 'drawing' twice.

However, we do need to make sure the alignment/output is the same in all cases of DPI/theme, etc... so it's not noticeable when the user switches between modes.

[salmanmkc]

@deanchalk and/or @salmanmkc were you still interested in taking another look at this? I think the underlying issue here is that we're trying to both render on the canvas directly and have the text box above.

I think when in 'Edit' mode we should just be using the TextBox itself, and when we're done switch back to the rendered version? I think this would make it more reliable without having to deal with it 'drawing' twice.

However, we do need to make sure the alignment/output is the same in all cases of DPI/theme, etc... so it's not noticeable when the user switches between modes.

Yeah makes sense, currently I don't think it's scaling well since it's not divisible by 4, hiding/showing wouldn't be necessary if it is perfectly aligned which I think I alluded to at the end of the PR I made and you followed up on mentioning the transparency during dark mode. Perfectly lining it up would be needed to give no effect of shifting. Could this potentially be something to do with the positioning of the box in the 'bounding box/canvas' area varying based on the scaling, rather than the margins of the actual edit box?

[michael-hawker]

@salmanmkc that seems like a smart idea to adjust the position of the text and then basically adjust the border position to 'snap' to a clear pixel spot based on the DPI? Kind of like a dynamic padding?

We definitely need to figure out how to align the edit/display modes, but definitely think we should just rely on one rendering for each vs. trying to 'hide' the textbox text. As long as we have the alignment figured out, it shouldn't matter, but I think it'd lead to the best results.