Synfig Issue Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
CLOSED  Bug report #154  -  Tremendous memory usage when importing large PNGs
Posted Dec 22, 2012 - updated Jan 05, 2019
action_vote_minus_faded.png
2
Votes
action_vote_plus_faded.png
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
     
    Closed
  • Assigned to
    Not assigned to anyone
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     Imported User
  • Owned by
    Not owned by anyone
  • Time spent
    3 days
  • Category
    Import
  • Resolution
    RESOLVED
  • Priority
    Not determined
  • Targetted for
    icon_milestones.png Not determined
  • Tags
    icon_customdatatype.png Not determined
  • Difficulty
    icon_customdatatype.png Not determined
Issue description
burginabc: When I import many large (high-res) PNGs into a scene, memory usage shoots up dramatically. My guess as to what's happening is that it is decompressing the PNGs upon import and storing the fully decompressed bitmap data in memory, which is hugely inefficient. Maybe the new Cairo based version you're working on doesn't have this issue and my point is moot because you're working on it anyway, but just want to inform you that the stable release has a huge issue with this.

it's on 64-bit ubuntu 12.10 "quantal" by the way. I have 4 GB of ram and with 15 large (Roughly 2000x2000) PNGs in the scene 3 GB of that memory is used, compared to 300MB while idle.

Steps to reproduce this issue
Nothing entered.

#2
Comment posted by
 Charlie Murphy
Jan 01, 21:32
I think keeping it compressed in memory would also be hideously inefficient. It would have to decompress the image on every frame to draw the pixels.

In the meantime you could use low-res placeholders. Before your final render, you can switch them back to the high-res images.

Any other ideas?
#3
Comment posted by
 Carlos López
Jan 02, 07:11
Use huge images only where absolutely needed. Render foregrounds separately and compose them with the backgrounds in a video editor. For that, use low resolution images when editing and disable the render of them using the latest feature of render disable option for layers.
#4
Comment posted by
 Konstantin Dmitriev
icon_reply.pngJan 02, 13:01, in reply to comment #2


Charlie Murphy wrote:
I think keeping it compressed in memory would also be hideously
inefficient.
It would have to decompress the image on every frame to draw the pixels.

In the meantime you could use low-res placeholders. Before your final
render,
you can switch them back to the high-res images.

Any other ideas?


I agree that the memory usage for the images is absolutely ridiculous in Synfig. Using low-res placeholders is not an option in my opinion. I think the images should be purely handled by Cairo loader or something like that. (AFAIK when cairo rendering mode is enabled then cairo loads image by itself, without relying on the image stored in memory. Carlos, please orrect me if I'm wrong. ^__^)

#5
Comment posted by
 blackwarthog
Sep 06, 16:50
Fixed https://github.com/blackwarthog/synfig/tree/rendering
#6
Comment posted by
 Konstantin Dmitriev
icon_reply.pngSep 07, 11:32, in reply to comment #5
blackwarthog wrote:
Fixed
https://github.com/blackwarthog/synfig/tree/rendering


I have tested the solution. For my test with a lot of imported images it now consumes 14 times ( ! ) less memory (100 Mb vs 1400 Mb). Although, the rendering speed now ~2,5 times slower (52ms vs 17 ms). Is it possible to do something about this?

P.S. I have pitched a bounty a bit ^__^ - https://www.bountysource.com/issues/1372043-tremendous-memory-usage-when-importing-large-pngs
#7
Comment posted by
 blackwarthog
icon_reply.pngSep 10, 16:19, in reply to comment #6
New code uses two methods to reduce image :
 - fixed some bugs :) - reduce some memory;
 - change format from RGBA-Float32 to RGBA-UInt8 - reduce memory 4 times;
 - Gzip-compression - additional reduce memory 2 times.


Gzip-compression takes a lot CPU-time and give approximate 50% compression. So i think we may to make gzip-compression optional. Also i need to tune minimal of image size for gzipping.
#8
Comment posted by
 Konstantin Dmitriev
icon_reply.pngSep 16, 10:16, in reply to comment #7
Results for test file with the latest changes:

  • Synfig 1.0.2 - 1.1 Gb
  • Synfig 1.1.1 (dev) - 1.4 Gb
  • Current (dev) - 0.4 Gb


The win is 3,5 (comparing to 1.1.1), and 2,75 (comparing to 1.0.2). The slowdown is only 3-4 ms. (comparing to (1.1.1).

Good work! ^__^
#12
Comment posted by
 Konstantin Dmitriev
icon_reply.pngNov 13, 15:35, in reply to comment #8
Here are the binary builds with memory fix - http://www.synfig.org/cms/en/news/synfig-studio-builds-updated-2/