[GH-ISSUE #453] Board with touchscreen not drawing as intended

kerem commented

2026-02-26 09:31:12 +03:00

Owner

Originally created by @TimDoesCode on GitHub (Feb 20, 2019).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/453

Originally assigned to: @NickeManarin on GitHub.

Hello,

I was just trying out the board function of your software and noticed something weird. When I draw something on the board using the mouse, i can actually see the drawing of the single strokes in the resulting gif.

If I use my touch monitor to actually draw on it, the resulting gif will have the completed strokes pop in as one. Also the last few strokes seem to be missing for some reason.

I've attached two gifs to this issue. Hi_Mouse.gif is me drawing via the mouse. H_Touch.gif is me drawing via the touch monitor.

I was using:
ScreenToGif v2.17
Windows 10 Pro x64
HP E230t touch monitor

Attachments:

Originally created by @TimDoesCode on GitHub (Feb 20, 2019). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/453 Originally assigned to: @NickeManarin on GitHub. Hello, I was just trying out the board function of your software and noticed something weird. When I draw something on the board using the mouse, i can actually see the drawing of the single strokes in the resulting gif. If I use my touch monitor to actually draw on it, the resulting gif will have the completed strokes pop in as one. Also the last few strokes seem to be missing for some reason. I've attached two gifs to this issue. Hi_Mouse.gif is me drawing via the mouse. H_Touch.gif is me drawing via the touch monitor. I was using: ScreenToGif v2.17 Windows 10 Pro x64 HP E230t touch monitor Attachments: ![hi_mouse](https://user-images.githubusercontent.com/33052115/53088219-665f2500-3509-11e9-93a5-103fcae3b0d9.gif) ![hi_touch](https://user-images.githubusercontent.com/33052115/53088225-68c17f00-3509-11e9-960a-d3c575d9d940.gif)

kerem added the

🔷 Bug 🐛

⬜ In Progress

⬜ Help Wanted 💪

labels

2026-02-26 09:31:12 +03:00

kerem commented

2026-02-26 09:31:12 +03:00

Author

Owner

@theJosher commented on GitHub (Oct 5, 2019):

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

@theJosher commented on GitHub (Oct 5, 2019): @NickeManarin I can look into this one if it hasn't been fixed yet.

kerem commented

2026-02-26 09:31:12 +03:00

Author

Owner

@NickeManarin commented on GitHub (Oct 5, 2019):

@theJosher Yes, please. Thank you.

@NickeManarin commented on GitHub (Oct 5, 2019): @theJosher Yes, please. Thank you.

kerem commented

2026-02-26 09:31:12 +03:00

Author

Owner

@theJosher commented on GitHub (Oct 17, 2019):

@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.

@theJosher commented on GitHub (Oct 17, 2019): @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 :sweat:. I'm curious which approach you would prefer, and if you have any other thoughts.

kerem commented

2026-02-26 09:31:12 +03:00

Author

Owner

@TimDoesCode commented on GitHub (Oct 17, 2019):

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

@TimDoesCode commented on GitHub (Oct 17, 2019): Hey, thanks for working on this. Hit me up if you need someone to test this on a touch monitor.

kerem commented

2026-02-26 09:31:12 +03:00

Author

Owner

@theJosher commented on GitHub (Oct 21, 2019):

@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.

@theJosher commented on GitHub (Oct 21, 2019): @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.

kerem commented

2026-02-26 09:31:12 +03:00

Author

Owner

@theJosher commented on GitHub (Oct 21, 2019):

@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 😃

@theJosher commented on GitHub (Oct 21, 2019): @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](https://github.com/theJosher/ScreenToGif) from whence the PR emerged 😃

kerem commented

2026-02-26 09:31:12 +03:00

Author

Owner

@theJosher commented on GitHub (Oct 21, 2019):

@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.

@theJosher commented on GitHub (Oct 21, 2019): @NickeManarin Incidentally, while fixing, I noticed the following ToDo: ```csharp // 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.

kerem commented

2026-02-26 09:31:13 +03:00

Author

Owner

@NickeManarin commented on GitHub (Oct 21, 2019):

@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 commented on GitHub (Oct 21, 2019): > @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: ![Via touchscreen](https://user-images.githubusercontent.com/14798947/67172687-a75a5280-f392-11e9-986b-28d349bc9fc3.gif) > Touchscreen, with flickering. Open gif in a new window to see better. ![Via mouse](https://user-images.githubusercontent.com/14798947/67172720-d8d31e00-f392-11e9-9a0c-2ecf3d00d787.gif) > 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](https://github.com/NickeManarin/ScreenToGif/files/3748860/ScreenToGif.zip)

kerem commented

2026-02-26 09:31:13 +03:00

Author

Owner

@NickeManarin commented on GitHub (Oct 21, 2019):

@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.

@NickeManarin commented on GitHub (Oct 21, 2019): > @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](https://github.com/NickeManarin/ScreenToGif/tree/master/ScreenToGif/ModelEx)). 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.

kerem commented

2026-02-26 09:31:13 +03:00

Author

Owner

@theJosher commented on GitHub (Oct 21, 2019):

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.

@theJosher commented on GitHub (Oct 21, 2019): > 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.

kerem commented

2026-02-26 09:31:13 +03:00

Author

Owner

@TimDoesCode commented on GitHub (Oct 21, 2019):

@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.

@TimDoesCode commented on GitHub (Oct 21, 2019): @NickeManarin I tested your version and can confirm that the initial issue is resolved. Mouse action: ![Hallo_Mouse](https://user-images.githubusercontent.com/33052115/67209808-568d3d00-f418-11e9-8054-c33770b813bf.gif) Touch action: ![Hallo_Touch](https://user-images.githubusercontent.com/33052115/67209828-5c831e00-f418-11e9-9785-e1d7dc339343.gif) I have also tried drawing with the mouse to see if I can get your flickering but so far no dice.

kerem commented

2026-02-26 09:31:13 +03:00

Author

Owner

@TimDoesCode commented on GitHub (Oct 21, 2019):

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

@TimDoesCode commented on GitHub (Oct 21, 2019): Actually, now that I see the touch gif you can actually see some flickering with the L chars?

kerem commented

2026-02-26 09:31:13 +03:00

Author

Owner

@theJosher commented on GitHub (Oct 26, 2019):

@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.

@theJosher commented on GitHub (Oct 26, 2019): @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.

kerem commented

2026-02-26 09:31:13 +03:00

Author

Owner

@theJosher commented on GitHub (Oct 31, 2019):

@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... 😭

@theJosher commented on GitHub (Oct 31, 2019): @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... :sob:

kerem commented

2026-02-26 09:31:13 +03:00

Author

Owner

@NickeManarin commented on GitHub (Oct 31, 2019):

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

@NickeManarin commented on GitHub (Oct 31, 2019): It's alright, I could not test it yet. :/

kerem referenced this issue

2026-02-26 09:33:42 +03:00

[PR #375] [MERGED] Add "Scale Delay" command #1117

kerem referenced this issue

2026-02-26 09:33:43 +03:00