Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upOptimize Qimage producer #573
Conversation
|
I agree with the ideas but 2 things:
|
|
I am interested in "Slightly faster check if image is readable on producer init" because the new slideshow feature in Shotcut will compel people to open many images at once. It would be good if you could share some rough metrics of how much the performance is improved with these changes. For example, How much faster can 100 images be loaded with this change? |
|
@ddennedy I agree that this is a rather large patch which makes it difficult to track possible issues as it mixes some refactoring with other optimizations. I will maybe try to come up with several smaller patches that implement the various changes with only the necessary changes :
@bmatherly In fact the speedup on producer init is very noticeable but it's because the image is not read anymore at that stage, only when requesting an image from it. I hope it's ok to proceed like this. Opening a project file with 75 images drops from 3 seconds to 0.3 seconds, but of course when displaying the images in monitor, they now need to be loaded. It also doesn't consume memory until the image is displayed. |
|
I might be missing something, but doesn't the overhead from flipping every pixel in the image to another format outweigh any cost of copying? and don't you at least need to check the stride? I don't think it's safe to assume that the lines are aligned perfectly, I'd at least memcpy scanLine() by scanLine(). |
| #endif | ||
| } | ||
| self->current_image = ( uint8_t * )mlt_pool_alloc( image_size ); | ||
| memcpy( self->current_image, scaled.constBits(), image_size); |
This comment has been minimized.
This comment has been minimized.
sandsmark
Aug 27, 2020
Contributor
you should at least check that scaled.sizeInBytes() is same or bigger than image_size so you don't read out of bounds.
j-b-m commentedMay 30, 2020
Looking at the QImage producer, I found several bottlenecks that I could improve:
Slightly faster check if image is readable on producer init (use QImageReader methods only to check image size and ensure it is readable instead of loading full image)
When transferring the QImage data, use the QImage::Format_RGBA8888 or QImage::Format_RGB888 to copy the image in one pass instead of doing a pixel copy
Disable caching for ttl=1 (image sequences with 1 image/frame). Caching scaled image does not make sense if we have an image sequence with 1 image/frame. Disable caching for those provides a noticeable speedup, in Kdenlive these sequences can now play at 20fps instead of 7fps on my machine.
Since this touches a rather important MLT component, comments are welcome.