Good news about Manjaro.
PLEASE still test the new ubuntu 19.10 build as the "draw line" routine mods made a significant speed up even on our newer/faster computers - the CPU usage would go from 50%+ down to 25%+.
https://cinelerra-gg.org/download/testing/cinelerra-5.1-ub19-x86_64-static.txz
"how do you switch between Wayland and X11?"
Fuzzy generic instructions that GG said to me for Mint 19.3 are:
1 install gnome desktop Wayland
2 start Run Level 3 (it might work at run level 5, but he did not try this and would like to know)
3 run: dbus-launch-program gnome-shell --desktop=wayland
(or something like the above in case I dictated it wrong)
Second, how do you switch between Wayland and X11? I did not see an obvious setting for that.
Wayland isn't enabled by default in Pop!_OS 19.10, you must comment the line that disable it in some conf file (it's the GDM conf file IIRIC), then you can select it in the login screen using the cog icon, the one that says only Pop OS (the other one should show Pop on XOrg). I use Wayland because browsing and other stuff is much faster, with less tearing, with my machine.
I will test the icon configurations later, but I am pretty sure @phyllissmith nailed it: the display servers I have installed have some problem with the draw lines functions used in CinGG, everything works fine as long as I don't display sound wave forms nor auto keyframes lines in the timeline.
@phyllissmith I was already using the 2020-03-31 build on Pop!_OS, it was replaced but somehow kept the same date?
Edit: never mind, I see now the new build is from a "testing" folder. I will download and try it today. Thanks!
There is no need to install anything on Ubuntu 19.04/19.10 to enable Wayland AFAIK, you simply need to comment a line that disables it when you login:
https://www.reddit.com/r/pop_os/comments/75wn18/how_do_i_start_wayland_session/
It was the default display server on 18.04 and it will be again on 20.04. Fedora uses it as default since 29 or 30 IIRIC. Latest Manjaro also have it enabled by default, but Gnome 3.36 has some quirks...
Good news about Manjaro.
PLEASE still test the new ubuntu 19.10 build as the "draw line" routine mods made a significant speed up even on our newer/faster computers - the CPU usage would go from 50%+ down to 25%+.
https://cinelerra-gg.org/download/testing/cinelerra-5.1-ub19-x86_64-static.txz
I had given up, but IT IS WORKING NOW! Even on Wayland, and with all auto keyframes and assets enabled! It is still a bit slow when showing audio waveforms, but totally bearable (and expected, I guess, due to my machine specs), the interface does not freeze for many seconds anymore!
I still have a small issue with sound output, but I will start a new thread. This one regarding the UI/UX is closed for me. I do hope that the snap and option to show only the starting/ending thumbnail are considered tho, it would make using CinGG much more pleasant, specially when running on a machine with lower specs.
Thank you all!
Moving on to next problem as this one is done!! BTW - the speed up in "line drawing" should benefit in lower CPU usage for other distros and will be checked into GIT today or tomorrow.I will log a BT on first and last thumbnail only but as previously stated it is doubtful that it will ever get implemented (BT # 408).
Forgot to mention earlier about "I noticed that "Show titles" is disabled when there is anything in the timeline the current titles remain, they aren't hidden. Known bug?" This was purposely implemented this way -- we discussed it again and decided that this was preferable. Basically what happens is that if you drag a plugin, for example, to the timeline it "expands" the track to show it and thus shows the title also, even though Show titles is not checked. To NOT see the titles, move left to the patchbay and turn off the expander (which is the left-right/up-down pointing arrow on the top line for that track).
Well I know that the slowness is resolved but since you reported the below (and I can not find the other forum because I am lazy):
"Regarding JPG/PNG: it doesn't work if I keep vaapi + ffmpeg first enabled, I have to disable ffmpeg first, import the images, then enable it again, while I keep vaapi enabled in settings, otherwise all I get are black thumbnails"
we have applied a fix here locally that works to load PNGs with vaapi + ffmpeg first enabled. At least on 2 of our laptops (one is intel with a Broadwell board and the other is amd with a Radeon board). Additionally some JPGs work; for example -
video1 mjpeg 5184x3888 25.00 pix yuvj422p WORKS with fix applied
video2 mjpeg 512x512 25.00 pix yuvj422p DOES NOT WORK
It is strange and as gg worked on debugging this problem again, the GPU says in the non-working case that everything is just fine and it can handle it and then does not. There is no error message to handle and no chance is provided to switch to software. Not sure if there is a solution here for some not working. Do you have a test jpg that fails so we can check it here easily? GG does not think adding a "quirk" for a strange case is a good idea.
Your results which you reported in the forum on "Multiple GPUs" where the Ubuntu 19 dated before 04-16 the PNGs and some of the JPGs worked but then none worked on the 04-16 Ubuntu 19 is consistent with what happened here. When GG made a fix for vdpau, a line got deleted that should not have been and that is the fix here locally.
@phyllissmith Attached is a JPG (with a dog) that loads only if vaapi is *disabled*, the other one is a cover art that works with the PulseAudio version either way (vaapi on or not), in this version PNGs work fine too.
Interesting. Thanks for the examples. I do not have a very capable board on my laptop. The DOG comes back with "Codec mjpeg profile 194 not supported for hardware decode" and loads just fine with software. The other one loaded just fine too, again with software. Another laptop without the latest mod installed here locally, neither loaded and then with the mod, both loaded using software because mjpeg profile 194 not supported.
Short answer - with this mod, both should load correctly with software.
With "vainfo" (if libva-utils installed) you can see if your hardware supports "profile 194" -- mine does not show it as is supported. I do not know if you have already done this, but it is very helpful when checking on hardware acceleration use if you modify {cinelerra_path}/bin/ffmpeg/decode.opts to have "loglevel=verbose" instead of "loglevel=fatal" -- you will get a lot of messages in the Cinelerra startup window which lets you know "profile 194 not supported" and other esoteric messages that are meaningful when analyzing.
@phyllissmith I think I did it here: https://www.cinelerra-gg.org/forum/postid/956/
Please let me know if you need further info.
Regards
Thanks for the followup. I went back and looked at it. I will see if GG can create a new Ubuntu 19 build with the latest mods in since you are willing to test BUT I do not know when that will be as he is in the middle of something time-consuming. Will let you know when and if.
About the following: "PulseAudio works as expected in the testing build. Alsa still does not work using the "default" output".
This is the exact opposite of the experience reported in the forum topic "Another Performance Query" where Alsa worked and PulseAudio did not (in a note a ways down in the discussion). At any rate I have scheduled Audio work for next month as it is difficult and may take several weeks so too late to begin this month.
@phyllissmith Don't worry about testing builds for UB19, only if you want me to test anything...
Yes, the PulseAudio test build didn't have ALSA working properly with "default" as output, but then I downloaded the newer build that was meant for someone else (as a mistake) and I installed as curiosity, and both ALSA and PulseAudio worked normally with "default" as setting, and honored system volume control.
