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

Lower performance when multiple images overlap #326

Open
Hedronmx opened this issue Apr 16, 2020 · 3 comments
Open

Lower performance when multiple images overlap #326

Hedronmx opened this issue Apr 16, 2020 · 3 comments
Assignees
Milestone

Comments

@Hedronmx
Copy link

Expected Behavior

Performance should be the same regardless of overlapping images

Current Behavior

When moving an image and it overlaps the responsiveness of the program decreases.

Possible Solution

Have some sort of culling engine? (No idea, using my game dev brain)

Steps to Reproduce (for bugs)

Import multiple images
drag an image on top of one or many images.

Context

I constantly work with high resolution images and this would make the software a pain to use

Screenshots of the Problem

https://gfycat.com/elatedpiercingkissingbug

Your Environment (for bugs)

Linux carlos-pc 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
NAME="elementary OS"
VERSION="5.1.3 Hera"
ID=elementary
ID_LIKE=ubuntu
PRETTY_NAME="elementary OS 5.1.3 Hera"
LOGO=distributor-logo
VERSION_ID="5.1.3"
HOME_URL="https://elementary.io/"
SUPPORT_URL="https://elementary.io/support"
BUG_REPORT_URL="https://github.com/elementary/os/issues/new"
PRIVACY_POLICY_URL="https://elementary.io/privacy-policy"
VERSION_CODENAME=hera
UBUNTU_CODENAME=bionic
  • Akira Version:
  • OS Info: 5.1.3 Hera Elementary Os
@Alecaddd
Copy link
Member

Hi,thanks for testing Akira.
We're not currently doing any optimization on the images as that's not in scope for the alpha release.

Nonetheless, this is a great report and we'll keep an eye on this behavior once we start refining this feature.

Currently we don't have any buffering, compression, caching, or optimization going on, so you're pretty much moving the full raw data all the times.

I'll keep this issue open as a future reference.

@Alecaddd
Copy link
Member

I finally found an easy solution for this, which I think is the same trick the Sketch and Figma use to deal with many large images.

We already have in place a DPI lowering method that re-renders the image based on their scaling. So if you import a 8000x8000 pixels image at 300 DPI, but you resize it down to 400x400, we recalculate the pixbuf to return an equally sharp image but for the new resolution, instead of compressing those 8K pixels in a smaller container, which affects performance and makes the image hard to see.

Currently, we don't do anything when zooming in and out the canvas, which in practice it's actually resizing the canvas size and all its items.

Solution: Reduce the image quality based on the Canvas zoom ratio.
So, if you're looking at the image at 100% Canvas zoom, in its entirety, we don't reduce the quality, because we safely assume that you're looking at a few large images at once, and you're not reorganizing large images all at once since potentially you don't have the screen real estate necessary to do that.

If you zoom out, for example at 50% zoom, we can recalculate the pixbuf of all the images currently inside the viewport, and return a slightly compressed version of those items, since you don't need to look at those at full quality, and you probably have many images in the viewport and you're interacting with those.

All this temporary "quality reduction" will obviously be ignored during export, which always grabs the maximum available resolution of the image, allowing users to reduce the quality independently.

@albfan
Copy link
Collaborator

albfan commented Feb 27, 2021

Davinci resolve uses same technique to deal with high resolution videos.

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

No branches or pull requests

3 participants