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.

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

Drawing app is very laggy on decent hardware #425

Closed
Netherquark opened this issue Oct 2, 2021 · 5 comments
Closed

Drawing app is very laggy on decent hardware #425

Netherquark opened this issue Oct 2, 2021 · 5 comments
Labels
duplicate This issue or pull request already exists enhancement ideas to improve existing features

Comments

@Netherquark
Copy link

Use case

I just use drawing to doodle/note down formulae while im studying and its surprisingly laggy for that use case. I use an AMD 2200G based system with 8GB of ram, utilising the integrated graphics, which is more than enough for a simple Paint-equivalent I'd reckon. I think the problem is probably related to hardware acceleration, or rather, a lack thereof.
I'm finding that as I use the pen/cil utility, the drawing lags behind and when I undo/redo, it lags for a solid 5 seconds or so before becoming functional again.

Suggested solution

I think working on hardware acceleration would help a lot.

@Netherquark Netherquark added the enhancement ideas to improve existing features label Oct 2, 2021
@maoschanz
Copy link
Owner

maoschanz commented Oct 2, 2021

as I use the pen/cil utility, the drawing lags behind

this is a problem related to the size of the canvas, and it will be improved with version 1.0.0, i suppose luxurious hardware is correlated with bigger displays so the issue is worse than with a normal older laptop

It could probably benefit from hardware acceleration but i've no idea if it's feasible before switching to GTK4

meanwhile you can use a smaller canvas and zoom in it, i suppose it would work better

when I undo/redo, it lags for a solid 5 seconds or so before becoming functional again.

this one is trickier because it's caused by the architecture of the history. Basically, an "undo" recomputes everything you did (except the undone operation) since the last time you saved the picture. If you don't save often, or use tools that require more complex computation (blurring, selection, etc.), it may take a lot of time

The app could "remember" more frequently the entire picture so there would be less to compute, but then it would use more RAM

@Netherquark
Copy link
Author

excited for V1 then!

I think for the latter, it might be a good idea to allow that in settings. Up to you though. It'll be a pretty bit of coding on your end.

@earboxer
Copy link

Basically, an "undo" recomputes everything you did (except the undone operation) since the last time you saved the picture. If you don't save often, or use tools that require more complex computation (blurring, selection, etc.), it may take a lot of time

The app could "remember" more frequently the entire picture so there would be less to compute, but then it would use more RAM

What if it just "remembered" 1 previous state, so a single undo/redo would perform well (Most drawing apps I know work this way, instead of allowing infinite undos)

@maoschanz
Copy link
Owner

it just moves the problem away of 1 step so idk if it would really fix anything

even if many simple drawing apps don't do that, the current design isn't an alien abomination, it's a basic implementation of non-linear editing, which is a cool feature: aside of the memory-efficient "infinite" history, it allows workflows like "undo several steps > add operations to the graph > redo the steps" for example. No user knows that detail i guess, but anyways it's cool. And the plan was that this history will also help to fix #123:

Although this process is more computationally intensive than directly modifying the original content, changing the edits themselves can be almost instantaneous

anyways i'm not the first one to implement this idea in an image editor, there are probably some design patterns out there to do it with lighter computation, maybe even examples, what's needed here is some plagi... some well-sourced research among other free software.

@maoschanz
Copy link
Owner

(closed because it's a duplicate of #200 and #168)

@maoschanz maoschanz added the duplicate This issue or pull request already exists label Oct 16, 2021
maoschanz added a commit that referenced this issue Oct 23, 2021
if "undo" is pressed several times in a short period (500ms), recompute the picture only once
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists enhancement ideas to improve existing features
Projects
None yet
Development

No branches or pull requests

3 participants