Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Slow undoing, and other history-related performance issues #200

Open
7 of 9 tasks
maoschanz opened this issue Mar 1, 2020 · 2 comments · May be fixed by #561
Open
7 of 9 tasks

Slow undoing, and other history-related performance issues #200

maoschanz opened this issue Mar 1, 2020 · 2 comments · May be fixed by #561
Assignees
@maoschanz
Labels
bug Something isn't working
Milestone
1.4

Comments

@maoschanz
Copy link
Owner

maoschanz commented Mar 1, 2020 •
edited

Description

Undoing is slow (and saturates a core of the CPU) if the history is long, and full of selection manipulations (blurring is the worst)

Steps to reproduce the bug

  1. open or create image
  2. lots of editing operations
  3. undo

System

  • Package format (flatpak, native package, snap?): flatpak
  • App version: 0.5.3 (unstable)

Suggested solution

  • Add special operation(s?) to the history corresponding to the state of the pixbuf when saving
    • is the initial state (blank canvas or original file) such a special operation? or an other type?
    • contributions from Improved undo performance. #561 made the states object-oriented
    • remember only the last saved state no and delete the other operations from the history? no
      • or keep all of them for now? what has been done for 0.6.0
      • only keep a few of them? --> limit the number of states, which will increase the number of operations between each older one
  • limitation: what happens if an user saves while an editing operation (selection? cropping?) is going on? nothing it's not the main pixbuf
  • when undoing, recompute only from that remembered pixbuf
  • use that pixbuf restoration process refactoring to improve the "reload from disk" action
  • make the history rebuilding asynchronous
    • since the number of operations will increase, undoing older operations will be slow: add feedback to the UI so the user knows it's normal (show the info banner while recomputing the image)
  • implement GFileMonitor support to tell the user his image has changed on the disk
@maoschanz maoschanz added the bug Something isn't working label Mar 1, 2020
@maoschanz maoschanz added this to the 0.6 milestone Mar 14, 2020
@maoschanz maoschanz mentioned this issue Apr 6, 2020
Closed
25 tasks
maoschanz referenced this issue Jul 7, 2020
@maoschanz
Hybrid history (states/operations) that kinda works
6acaf10 
still issues with redoing states, and untested state yeeter
maoschanz added a commit that referenced this issue Sep 1, 2020
@maoschanz
Abandon (for now) the idea of removing states from history
c0d593c 
since it can result in incoherent reconstructions. #200
@maoschanz maoschanz changed the title Slow undoing Slow undoing, and other history-related performance issues Sep 2, 2020
@maoschanz maoschanz modified the milestones: 0.6, 0.6.x Sep 2, 2020
@maoschanz maoschanz mentioned this issue Oct 7, 2020
Closed
maoschanz added a commit that referenced this issue Oct 10, 2020
@maoschanz
suggest to reload from disk after saving without transparency
6718318 
vaguely related to #200
@maoschanz maoschanz modified the milestones: 0.6.x, 0.8.x Mar 5, 2021
@maoschanz maoschanz modified the milestones: 0.8.x, 2.0.0 Oct 16, 2021
@maoschanz maoschanz mentioned this issue Oct 16, 2021
Closed
maoschanz added a commit that referenced this issue Oct 23, 2021
@maoschanz
probably nice history performance optimization (#425, #435, #282, #200)
be18c7d 
if "undo" is pressed several times in a short period (500ms), recompute the picture only once
@maoschanz maoschanz self-assigned this Dec 18, 2021
@maoschanz maoschanz modified the milestones: 2.0.0, 1.2.0 Mar 27, 2022
@gulis1
Copy link

gulis1 commented Nov 26, 2022

While working on some improvements to the history-manager, I noticed the behavior of the redo button is different to other applications, since it does not clear the redo history after the user inputs a new action.

For example, here:
Peek 2022-11-26 14-32

After drawing the horizontal line, most similar applications would clear the redo-history and disable the redo button.

Is this behavior intentional, or should I try to fix it as well?

@maoschanz
Copy link
Owner Author

it was intentional, but if you're trying to improve perf and that feature gets in the way, you can totally remove it

@gulis1 gulis1 linked a pull request Nov 27, 2022 that will close this issue
Open
@maoschanz maoschanz modified the milestones: 1.2.0, 1.4.0 Jan 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@maoschanz maoschanz

Labels
bug Something isn't working
Projects
None yet
Milestone
1.4
Development

Successfully merging a pull request may close this issue.

Improved undo performance. gulis1/drawing
2 participants
@maoschanz @gulis1