Flowblade 2.14 Video Editor Released, GTK4 Port Hopefully Ready Next Year

[Quackdoc]

It does not. That workaround is only partial. The full solution requires that MR 3393 be resurrected and merged, which judging from the vibes requires Mattias Classen to repent and abandon his incorrect beliefs about the importance of static vs animated text. Unless and until GTK4+ has subpixel antialiasing, it is unfit for purpose at less than 200 PPI, which is basically only smartphones and $1000+ laptops (and only some of those; PPI trades off with battery life and other specs). Or, I suppose it's okay for single-purpose applications that you don't keep open or use regularly, like overclocking tools and CD burners.

ah the issue was low dpi text. Yeah I have a 4k display so that wont effect me. but not allowing any subpixel aa is a weird stance.

[sophisticles]

Kdenlive, shotcut, openshot and flowblade are all based on MLT.

Shotcut supports GPU powered filters, and hardware encoding.

The GPU filters really improve performance, using them can make a long full length render 3 times faster.

[You-]

The best thing about text rendering cults is everyone thinks they know perfectly what is right... but often wont even be able to tell which one is which.

The sharpest font rendering you can get is probably the Windows 95/98/XP style (without cleartype turned on). No rounding, no attempting to make fonts look anything other than pixelated. But totally horribly sharp. If sharpness is the only metric we can all go home, it was solved 30 years ago.

[Quackdoc]

The best thing about text rendering cults is everyone thinks they know perfectly what is right... but often wont even be able to tell which one is which.

The sharpest font rendering you can get is probably the Windows 95/98/XP style (without cleartype turned on). No rounding, no attempting to make fonts look anything other than pixelated. But totally horribly sharp. If sharpness is the only metric we can all go home, it was solved 30 years ago.

I don't understand this comment, While it's true that sharpness in isolation is not a decent way of judging good quality, It is undoubtedly true that blurryness in isolation, the inverse of sharpness is a good way of judging poor quality since regardless of how good any other factor is, if it's too blurry it will never be good. Sharpness is not the only metric. but it's probably the single largest piece of the quality pie, or at least tied for that position.

[sobrus]

Did someone use this editor and can share their experience?

Video editing in Linux, at least if we consider open source alternatives, has always been terrible.

The better editor I used was Kdenlive, but it still was very featureless and crashed often. I also used Open shot and another one that I don't remember the name.

'Ive never heard of this Flowblade before.

I'm using it, albeit rarely and for simple things. I like it. It's a small app. Some things, like keyframes, are implemented in a different way than most other video editors. Proxy video works as advertised, it has support for hardware accelerated encoding (also for proxy), you can also use prores if you like. Supports 4K without problems.
It may be written in Python, but it's quite fast, much faster than OpenShot I used to use which could not play poststamp-sized video smoothly on a 5950x lol. Heavy lifting is done using MLT anyway. Output options - anything ffmpeg can output, you can provide your own settings.

Disadvantages? It doesn't (yet) use GPU hardware acceleration besides hardware encoding. And it redraws the video preview all the time, so may unnecessarily tax your CPU. It's author doesn't want to fix it for performance reasons.

I've tried Shotcut as well but liked this one better. Shotcut is my "second best".

[ssokolow]

The best thing about text rendering cults is everyone thinks they know perfectly what is right... but often wont even be able to tell which one is which.

The sharpest font rendering you can get is probably the Windows 95/98/XP style (without cleartype turned on). No rounding, no attempting to make fonts look anything other than pixelated. But totally horribly sharp. If sharpness is the only metric we can all go home, it was solved 30 years ago.

Exactly. When I repurposed an HP t5530 thin client as a tiny Win98SE machine about a month ago, I realized how far I'd fallen. (It reminded me of the "*sigh* I'm home!" moment when, having grown up on laptops, I finally replaced my desktop CRT with my first desktop LCD.)

It's very striking when the leftmost of the three monitors on my daily driver can be switched to VGA input to show that Win98SE machine side-by-side with the modern desktop and, when I do, it puts the text crispness of the other two to shame.

Since then, I've been trying to figure out what aspect of my KDE font configuration is sub-optimal for getting that crispness I see on my Windows 98SE and Mac OS 9 machines, when it should be right to achieve that.

[Daktyl198]

The best thing about text rendering cults is everyone thinks they know perfectly what is right... but often wont even be able to tell which one is which.

The sharpest font rendering you can get is probably the Windows 95/98/XP style (without cleartype turned on). No rounding, no attempting to make fonts look anything other than pixelated. But totally horribly sharp. If sharpness is the only metric we can all go home, it was solved 30 years ago.

(As a cult member myself) the best font rendering we ever had on Linux was Infinality, and I feel like everybody forgot it existed once it got merged into Freetype2 because they assume that freetype uses those patches by default, when it's the opposite. The freetype people have done all they can to bury the Infinality patches and make people forget that they exist, and instead used a hacked-down version of it that the freetype people made for "speed" (who the hell needs speed when rendering fonts??).

For the record, Infinality is render mode 38 in the freetype config, but they only tell you about 35 (classic, pre-infinality) and 40 (their default now, the hacked down version of infinality).

People who want or need to be able to stare at text for 8-12 hours a day for work and not get eye fatigue or strain, and who just want to not look at ugly text are not "cultists". They just don't want blurry text, but also don't want pixelated nonsense from 30 years ago. Surely there's a middle ground?

[lumks]

It was never my statement in the first place. I was just saying "I think this is what they're talking about it".



My only issue with GTK is that they spent over a decade building up people's trust that GTK 1.x and GTK+ 2.x were a safe base to build all sorts of non-GNOME desktops and apps on, and now, with GTK 3 and GTK 4, they're incrementally forcing GNOME-isms on non-GNOME GTK apps that don't have the manpower to rewrite on top of a new toolkit.

"They" dont do. In fact, thganks to community input, the remaining GNOME-isms was ported into an own library (libadwaita). So the pure GTK apps can be without any dependencies on GNOME. The fact that GTK itself moves into a simpler direction just comes down to that there aren't many people working on it and that many parts just dont need to be inside of it anymore, but can be outside parts of the app/project that uses it.

If they weren't indirectly making a mess of tools with no suitable Qt alternatives like Inkscape, I'd have no problem with it whatsoever.

Thats to be honest your problem. Nobody in the real wold cares about the toolkit an app uses as long as it runs.

(Some people do care. That's why GNOME 3 prompted the creation of Cinnamon and MATE and why their "run stock GNOME or GTFO" demands prompted System76 to GTFO and develop COSMIC. GNOME has single-handedly done more for desktop fragmentation than any other group in the last 20 years.)

That happens if you build a product with a direction and other products that try to base on it with another direction. There is no one to blame here. S76 wanted a product that was just not compatible to GNOMEs vision so they build it without GNOME. That's absolutely fine and I hope more projects will do that, because thats more healthy for the ecosystem and developers as well.

[ssokolow]

"They" dont do. In fact, thganks to community input, the remaining GNOME-isms was ported into an own library (libadwaita). So the pure GTK apps can be without any dependencies on GNOME. The fact that GTK itself moves into a simpler direction just comes down to that there aren't many people working on it and that many parts just dont need to be inside of it anymore, but can be outside parts of the app/project that uses it.

And yet GTK 3 is the only version of KDE's Breeze theme that can't seem to turn off the buggy shadows on menus in non-libadwaita applications like Inkscape... and, though I stopped developing for GTK at the 2-to-3 transition because Qt had nicer building blocks, I've seen various other developers lamenting the libhandy-to-libadwaita transition forcing them to either maintain vendored widgets or accept Adwaita theming semantics to get functionality they used to get with non-adwaita theming via libhandy.

Thats to be honest your problem. Nobody in the real wold cares about the toolkit an app uses as long as it runs.

People in the real world care about whether an application is buggy, and those bugs are in GTK, not Inkscape, so they show up in any and every GTK 3 app I haven't yet managed to find a replacement for.

That happens if you build a product with a direction and other products that try to base on it with another direction. There is no one to blame here. S76 wanted a product that was just not compatible to GNOMEs vision so they build it without GNOME. That's absolutely fine and I hope more projects will do that, because thats more healthy for the ecosystem and developers as well.

And yet, in the GTK 2 era, there was a lot less duplication of effort because the GTK maintainers were much less rigid about people sharing their effort. Again, there's a reason Cinnamon, MATE, COSMIC, and the LXDE→LXQt transition didn't come into existence during the GTK 2 era.

[andre30correia]

always the same thing, gtk vs qt flame war. nothing new, the question here is this video editor is good or not?