mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-25 23:25:52 +03:00
[GH-ISSUE #487] Artifacts of moving windows when recording #408
Labels
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ScreenToGif#408
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @andrecool-68 on GitHub (May 30, 2019).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/487
If disable the option "enable desktop composition" in windows 7 ...then these artifacts disappear
In windows 10 it's impossible to get rid of this artifact
enabled
enable desktop compositiondisabled
enable desktop composition@NickeManarin commented on GitHub (Jun 26, 2019):
The artifact that you are seeing (second gif) are due to the color quantization process. It's only possible to reduce its effect when disabling the option to paint unchanged pixels with a dummy color (chroma key).
@andrecool-68 commented on GitHub (Jun 26, 2019):
@NickeManarin
The artifact occurs on the first animation!
The second image is fine ... and there are no artifacts!
@andrecool-68 commented on GitHub (Jun 26, 2019):
@NickeManarin This artifact occurs during the screen recording process ... and not during the editing process.
@NickeManarin commented on GitHub (Jun 30, 2019):
I can see artifacts in both gifs. I'm aware of the artifacts of the second gif, when you move the window, there's some pixels with the wrong shade of the color. This happens because of the gif encoder trying and failing to find the right color.
Now, the first gif shows a trail of the window border. I'm not sure what's happening. Have you tried to disable that option, so when the window is dragged, it will move in place, instead of just the border.
I remember that got the same issue back when I was using Windows 7, specially when the computer was slow and the graphics adapter was not handling so well all changes.
@andrecool-68 commented on GitHub (Jun 30, 2019):
@NickeManarin
The second animation works perfectly!
In these examples only the window frame should be moved (without its contents!)
sorry me for my bad english
@NickeManarin commented on GitHub (Jul 16, 2019):
@andrecool-68 So, you are saying that the window border is getting glitched like that only when recording?
@andrecool-68 commented on GitHub (Jul 17, 2019):
@NickeManarin
Exactly! This happens already in the recording of the animation on the desktop.
This can be seen as happening when dragging internal windows into Notepad++.
@NickeManarin commented on GitHub (Sep 27, 2019):
I think that you need to contact Notepad++ devs and show this issue to them. It's something out of my control.