@NickeManarin I can look into this one if it hasn't been fixed yet.

@theJosher Yes, please. Thank you.

@NickeManarin Curious what your thoughts are: Based on a lot of reflection, it looks like mouse rendering is happening in the UI thread, but any inking (via stylus or touch) is happening in a separate inking thread within a couple of real time ContainerVisuals, and strokes are transitioned to the UI thread at stylus up. Getting the inking over to the UI thread periodically mid-stroke proves difficult because of course the visuals can't be frozen, but I believe I can bring over a combined DrawingGroup with copies of each DrawingGroup as frozen and combine that with the DrawingGroup of the container in the main UI (or with the srokes from the InkPresenter). This approach involves reflection to get to private members, and I'm curious if you prefer it over, say, just doing a screen grab. The real shame is that I suspect the HostVisual is automagically handling composition between the two threads for the screen, but this all seems to be happening behind closed doors, my Googling is failing me here, and there remains the possibility I'm out of my depth 😓. I'm curious which approach you would prefer, and if you have any other thoughts.

Hey, thanks for working on this.
Hit me up if you need someone to test this on a touch monitor.

@NickeManarin Let me know if you'd like any revisions on my pull request. Otherwise, I think I've submitted the last of it. My 3-year-old and 6-year-old both volunteered to draw on my X230 tablet yesterday and after 2 hours of observing them use my forked code, I saw only one issue, where the overlay persisted after a discard. This last commit to the PR branch should solve that.

@TimDoesCode I think if/when @NickeManarin merges the PR would be a good time to do some testing. If you have a burning desire to try it out, you can find the fix in my fork from whence the PR emerged 😃

@NickeManarin Incidentally, while fixing, I noticed the following ToDo:

// TODO: Too heavy! Maybe just save the strokes? like layers?

I have been pretty enamored with inking with MS windows on tablets (since years before the competing "iPad" was a thing 🤣 ), so if you have an issue open for this you want to assign to me, I would gladly discuss implementation with you and work it.

@NickeManarin Curious what your thoughts are: Based on a lot of reflection, it looks like mouse rendering is happening in the UI thread, but any inking (via stylus or touch) is happening in a separate inking thread within a couple of real time ContainerVisuals, and strokes are transitioned to the UI thread at stylus up. Getting the inking over to the UI thread periodically mid-stroke proves difficult because of course the visuals can't be frozen, but I believe I can bring over a combined DrawingGroup with copies of each DrawingGroup as frozen and combine that with the DrawingGroup of the container in the main UI (or with the strokes from the InkPresenter). This approach involves reflection to get to private members, and I'm curious if you prefer it over, say, just doing a screen grab. The real shame is that I suspect the HostVisual is automagically handling composition between the two threads for the screen, but this all seems to be happening behind closed doors, my Googling is failing me here, and there remains the possibility I'm out of my depth 😓. I'm curious which approach you would prefer, and if you have any other thoughts.

I'm sorry that I could not reply in time. I would say to follow the easier path, or the one that hit less the performance. :)

@NickeManarin Let me know if you'd like any revisions on my pull request. Otherwise, I think I've submitted the last of it. My 3-year-old and 6-year-old both volunteered to draw on my X230 tablet yesterday and after 2 hours of observing them use my forked code, I saw only one issue, where the overlay persisted after a discard. This last commit to the PR branch should solve that.

Nice PR, thank you for your help.
I'm testing on a borrowed Dell 5548 notebook and I detected some small flickering, I'm not sure if it's just my device or if it's common. See:

Touchscreen, with flickering. Open gif in a new window to see better.

Mouse, no flickering.

The flickering is variable, not sure if because I was testing with a screen DPI of 125%. While I was using the mouse, I could not see any flickering at all.
I could not find any performance hit, so that's nice. :)

Btw, @TimDoesCode I attached the test version if you wish to help us.
ScreenToGif.zip

@NickeManarin Incidentally, while fixing, I noticed the following ToDo:
// TODO: Too heavy! Maybe just save the strokes? like layers?
I have been pretty enamored with inking with MS windows on tablets (since years before the competing "iPad" was a thing 🤣 ), so if you have an issue open for this you want to assign to me, I would gladly discuss implementation with you and work it.

Oh, about that...
I'm planning to change how the editor works, to enable support for layers.
The background of the board recorder will be the canvas and the strokes will be the layers.
The user will be able to interact with each layer independently, even edit/erase strokes.

I already started working on the new editor (here is the model).

Here's my current plan:

• I'm finishing implementing a faster recorder with Screen Duplication API (DirectX, I'm having trouble showing the mouse cursor in the recording).
• The frames are going to be stored in a (configurable 1Mb - ??? Mb) memory buffer as a simple pixel array (which taxes less the HD, good for computers with slow drives).
• The editor will support layers (I have to implement a proper timeline control to handle all that).
• Editor should have a proper MVVM architecture.
• The frame viewer is going to use a WriteableBitmap with it's back buffer receiving each frame's pixel array, allowing a faster rendering of the image.

It's going to take a while to finish, since I'm working on this app during weekends. Any help would be appreciated.

The flickering is variable, not sure if because I was testing with a screen DPI of 125%. While I was using the mouse, I could not see any flickering at all.

I think I may see what you're talking about. Is it that it is bouncing left/right or up/down by about a pixel in the capture of the real-time inking? If so, this probably has something to do with the way I'm setting margins on the overlay. Maybe rounding error. I'll take a look this evening when I'm back from work and see if I can track it down and get another commit in.

@NickeManarin I tested your version and can confirm that the initial issue is resolved.

Mouse action:

Touch action:

I have also tried drawing with the mouse to see if I can get your flickering but so far no dice.

Actually, now that I see the touch gif you can actually see some flickering with the L chars?

@NickeManarin The latest commit should fix the distortion. I am not sure, but it seems that although I was passing double precision margins to the Image control, the control is truncating them in placement, resulting in some scaling of the overlay, which is why its position would appear to drift. I couldn't find any properties on the DrawingGroup or Image control preventing cropping the drawinggroup such that TopLeft winds up at (0,0), so I instead placed a tiny transparent point at (0,0) in the drawingGroup and as such was able to remove the margins adjustment. I don't necessarily like this in principle, but in all practicality it works and is theoretically just as efficient. Let me know what you think.

@NickeManarin You probably want to hold of testing this a little longer. I just found a problem with the new approach when going off the canvas, which had been solved by negative margins in the previous approach, but which slipped my mind when changing the solution. Sorry... 😭

It's alright, I could not test it yet. :/