windows: fix transferToBase64 thread affinity

[jaimecbernardo]

Fixes transferToBase64 thread affinity for compatibility with react-native-windows >= 0.64.

[dd-apt]

Just tested this out on our 0.64 project and can confirm it works for us.

[jaimecbernardo]

Thanks for the update @dd-apt 😄

[jaimecbernardo]

I've added a commit to use UIManager.getViewManagerConfig, since the old method of accessing Constants and Commands doesn't work on 0.64 release as well.

[dd-apt]

@jaimecbernardo thanks for pushing this update!

Can confirm this is working in release build for 0.64. One thing I noticed is, there seems to be some delay now between drawing and when an item appears. Wondering if UIManager.getViewManagerConfig('RNSketchCanvas') is a performance-intensive call? Perhaps there is a way to cache it to be hit only once?

Other thing we've found is unrelated to the last change, but thought I'd mention it anyhow! Noticed when inside of a ScrollView using touch-input can't draw anything in the SketchCanvas. I believe this is due to the mouse-move event being passed up to ScrollView? So, when moving mouse around in canvas, results in only an initial (on mouse-down?) dot, then the ScrollView moving up and down but nothing being drawn.

[jaimecbernardo]

Hi @dd-apt ,

Can confirm this is working in release build for 0.64. One thing I noticed is, there seems to be some delay now between drawing and when an item appears. Wondering if UIManager.getViewManagerConfig('RNSketchCanvas') is a performance-intensive call? Perhaps there is a way to cache it to be hit only once?

This is another issue that I'm still trying to get a simpler repro for: microsoft/react-native-windows#7537 (comment)

Other thing we've found is unrelated to the last change, but thought I'd mention it anyhow! Noticed when inside of a ScrollView using touch-input can't draw anything in the SketchCanvas. I believe this is due to the mouse-move event being passed up to ScrollView? So, when moving mouse around in canvas, results in only an initial (on mouse-down?) dot, then the ScrollView moving up and down but nothing being drawn.

I'm not sure about this one. Unfortunately I don't currently have a touch device available to test this. Is this a Release issue or it happens in Debug as well?

[dd-apt]

I will keep an eye on that other issue!

As far as the scroll view problem, seems to happy regardless of debug / release. Wondering if maybe there's some way to prevent an event from propagating up the chain. So that the mouse events are only capture in SketchCanvas component (and not the ScrollView)?

[jaimecbernardo]

As far as the scroll view problem, seems to happy regardless of debug / release. Wondering if maybe there's some way to prevent an event from propagating up the chain. So that the mouse events are only capture in SketchCanvas component (and not the ScrollView)?

I'm not sure about this, it's an issue I haven't encountered yet. It seems to work without much issue in Android and iOS. I suppose it'd really depend on where the pan response is being caught.

[creambyemute]

@jaimecbernardo Hey, I'm just on the way of upgrading our react-native project to 0.64 and will be happy to give this a try once I finished the rn-windows upgrade.

[jaimecbernardo]

Hi @creambyemute ,
This PR fixes some issues with 0.64, but there's still at least another unsolved issue with running on Release, which might affect your app. I've opened an issue here:
microsoft/react-native-windows#7543

For now, I recommend sticking with 0.63 if this issue affects your app.

[creambyemute]

I'll leave the 0.64 upgrade in a branch for our project and test around a bit.

Edit: I aborted the RN 0.64 upgrade for now due to problems with react-native-fs on RN-Windows 0.64 which is a core functionality for us.

[jaimecbernardo]

The module now works again on the latest react-native-windows 0.64.4

@creambyemute , this PR shouldn't break anything on 0.63, so it should be safe to let it go in.

[creambyemute]

I'll try to get both (0.63/0.64) running tomorrow and merge it if I don't find a problem.

[creambyemute]

@jaimecbernardo How did you go about finding out which library is the culprit of causing the white screen on RNW 0.64 Release Mode?

I can't get past the white screen in our 0.64 project with release mode and there is basically no output/error whatsoever and we're using a few native modules.

I'll test this PR in a fresh 0.64 Init with only this added as native dep and in our 0.63 project branch.

[jaimecbernardo]

@creambyemute , it was the process of looking into the source code and looking for suspects and trying to remove them, on a separate project that just used the module.
Just in case, do yarn cache clean before installing, just to make sure it's not using an older version of this PR.

[jaimecbernardo]

I've found that when trying simple samples, I have to disable dark mode on the OS, due to dark mode making the text white on top of the white background setting on older samples.

[creambyemute]

@jaimecbernardo Sounds like a fun process then... I did checkout the project and modify the dependency from before running yarn and building.

I have now tried this PR in a fresh 0.64 init project in Debug as well as Release mode.
In Debug Mode there is as mentioned by @dd-apt a quite long delay between moving the mouse/touch and drawing the line which is not apparent in Release mode for me.

The PR didn't seem to affect our 0.63 project in neither Debug nor Release Mode though, so that is fine for me 👍.

I'll quickly test on iOS/Android and merge if all is good and continue the white screen issue in microsoft/react-native-windows#7537 (comment) as it's not related to RN-SketchCanvas anymore. Gotta find out which of the multiple native libraries are causing this.

Edit: Looks good on iOS/Android 0.63 and 0.64. Will merge now

[jaimecbernardo]

Thank you!
For this module, this fixed the white screen issue: microsoft/react-native-windows#7537 (comment)

[jaimecbernardo]

In Debug Mode there is as mentioned by @dd-apt a quite long delay between moving the mouse/touch and drawing the line which is not apparent in Release mode for me.

Interesting, perhaps the fix made it slower.
I've always seen Debug mode being slower when compared to Release when drawing.