https://bugs.kde.org/show_bug.cgi?id=497435
--- Comment #22 from Ron <kdenlive-b...@contact.dot-oz.net> ---
And working my way up the tree, here's a patch that makes mlt
0c22797bbcb209f9667d72d4038866f28a624115
scroll smoothly with both hyper and bilinear interpolation (should work with
all, but only testing those two right
now as the representative cases).
diff --git a/src/modules/qt/filter_qtblend.cpp
b/src/modules/qt/filter_qtblend.cpp
index e1d0a8fb..2c2e2759 100644
--- a/src/modules/qt/filter_qtblend.cpp
+++ b/src/modules/qt/filter_qtblend.cpp
@@ -95,9 +95,13 @@ static int filter_get_image( mlt_frame frame, uint8_t
**image, mlt_image_format
transform.translate(rect.x, rect.y);
opacity = rect.o;
hasAlpha = rect.o < 1 || rect.x != 0 || rect.y != 0 || rect.w
!= *width || rect.h != *height;
- b_width = qMin( (int)rect.w, b_width );
- b_height = qMin( (int)rect.h, b_height );
- if ( b_width < *width || b_height < *height )
+ if ( qMin( qRound(rect.w), b_width ) < *width || qMin(
qRound(rect.h), b_height ) < *height )
{
hasAlpha = true;
}
diff --git a/src/modules/qt/transition_qtblend.cpp
b/src/modules/qt/transition_qtblend.cpp
index 07d40619..7da7a5d9 100644
--- a/src/modules/qt/transition_qtblend.cpp
+++ b/src/modules/qt/transition_qtblend.cpp
@@ -88,8 +88,8 @@ static int get_image( mlt_frame a_frame, uint8_t **image,
mlt_image_format *form
}
transform.translate(rect.x, rect.y);
opacity = rect.o;
- b_width = qMin((int)rect.w, b_width);
- b_height = qMin((int)rect.h, b_height);
+ b_width = qMin(qRound(rect.w), b_width);
+ b_height = qMin(qRound(rect.h), b_height);
}
else
{
@@ -248,7 +248,8 @@ static int get_image( mlt_frame a_frame, uint8_t **image,
mlt_image_format *form
bool hqPainting = false;
if ( interps )
{
- if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
+// if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
{
hqPainting = true;
}
The main things I'm uncertain of in this one is whether *anything* else in
filter_qtblend needs the adjusted value of b_width/b_height (and I've
reintroduced the original bug this was fixing) - but it seems adjusting it
there just causes the inaccuracy and jitter we're seeing.
And I tested nearest interpolation with the hqPainting change and it too is
much smoother - so I think I'd recommend just always enabling hgPainting unless
someone has benchmarks that show it really is expensive to want "worse than
nearest neighbor results" for (maybe?) gaining a little speed.
I'll come back to this again in a bit and look at the next commits up the chain
- but figured I'd share what I know now to see if there's any useful review on
this by the time I'm back to it again (and so we're not duplicating effort
analysing it :)
--
You are receiving this mail because:
You are watching all bug changes.
