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

Disable rendering in background by default #1170

Closed
ice0 opened this issue Feb 21, 2020 · 5 comments
Closed

Disable rendering in background by default #1170

ice0 opened this issue Feb 21, 2020 · 5 comments
Milestone

Comments

@ice0
Copy link
Collaborator

ice0 commented Feb 21, 2020

We have negative feedback from our users, so i suggest to disable it by default until it will be polished and production ready.

@morevnaproject your opinion?

@ice0 ice0 added this to the v1.4.0 milestone Feb 21, 2020
@Svarov-RZM
Copy link
Contributor

Svarov-RZM commented Feb 22, 2020

I personally fully support this. The problem is, the more complex the artwork, the more lags the "Background rendering" introduces to the point where the animation couldn't even load. The reason for this is that rendering for each frame takes too much time and GUI thread 'swallows' any input so you can't even disable the background rendering.

Try loading and work with this animation in 1.3.12: https://forums.synfig.org/t/cinematographic-computer-interface-made-in-synfig/9465
I made it using Synfig 1.0.2/Windows 10/Intel Core i5 650. And on my computer I cannot even load it in said Synfig version. It just blocks in rendering after loading.

As an alternative solution, we can leave it enabled, but make an option in "Preferences" called something like "Disable background rendering" so user would have a more solid option to disable it for all projects.

@rodolforg
Copy link
Contributor

rodolforg commented Feb 23, 2020

The background rendering should be a bit smarter:

  • don't struggle with GUI (maybe less threads?)
  • don't render frame twice (one for workarea and other for thumbnail; maybe the thumbnail could be a simple downscale of the rendered workarea cache - it seems faster than process whole layer tree again)

But, indeed, it gives a bad impression how slow and laggy the interface suffers when user does a simple change.

@morevnaproject
Copy link
Member

morevnaproject commented Feb 24, 2020

As an alternative solution, we can leave it enabled, but make an option in "Preferences" called something like "Disable background rendering" so user would have a more solid option to disable it for all projects.

There is one more idea: we can make "Background rendering" button (the one at the top of workarea) behave globally - i.e. it can enable/disable background rendering for all opened (and created) documents. And make Synfig remember its status when application closed. So, user can choose to work with it or not.

don't render frame twice (one for workarea and other for thumbnail; maybe the thumbnail could be a simple downscale of the rendered workarea cache - it seems faster than process whole layer tree again)

I've had impression this already works like that. Do we have all frames rendered twice? O__O

@morevnaproject
Copy link
Member

morevnaproject commented Feb 29, 2020

Okay, I agree to make Background Rendering disabled by default.

@rodolforg
Copy link
Contributor

rodolforg commented Apr 16, 2020

I've had impression this already works like that. Do we have all frames rendered twice? O__O

@morevnaproject That's what I suppose when I read this , for example:

if (future_exists && (!past_exists || future_priority)) {
// queue future
if (enqueue_render_frame(renderer, canvas, current_thumb.rect(), current_thumb.with_time(future_time)))
++enqueued;
if (enqueue_render_frame(renderer, canvas, window_rect, current_frame.with_time(future_time)))
++enqueued;
++future;
} else {
// queue past
if (enqueue_render_frame(renderer, canvas, current_thumb.rect(), current_thumb.with_time(past_time)))
++enqueued;
if (enqueue_render_frame(renderer, canvas, window_rect, current_frame.with_time(past_time)))
++enqueued;
++past;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants