RawTherapee 5.4 AppImage font issue


(Carmelo Dr Raw) #41

That’s still quite a lot, and significantly more than what I observe on other systems… if you have some time to help me dig into this, here is what I propose to do:

  • install bsdtar and valgrind if you do not have them yet
  • extract the AppImage:
mkdir $HOME/RawTherapee.AppDir && cd $HOME/RawTherapee.AppDir
bsdtar xfp /path-to-where-you-downloaded-the-appimage/RawTherapee-dev-5.4-271-gfde0dccd.AppImage

Edit the AppRun script, comment out the last-but-one line and un-comment the last one, that should look like this:

#valgrind --tool=callgrind --instr-atstart=no "./bin/rawtherapee" "$@"

Start RT like this

./AppRun

Open a second terminal, and issue this command just before clicking on a main tab:

callgrind_control -i on

followed by

callgrind_control -i off

as soon as the tab switching is completed. Then exit RT.

This will save a function call graph under $HOME/RawTherapee.AppDir/usr/callgrind.out.<pid> that can be visually inspected with kcachegrind. Please send me this callgrind output, hopefully it will give us some hint of what functions are taking so long to complete…

Using the method above, I traced the slowness down to some librsvg calls. What is strange is that AFAIK RT is not loading any .svg icon, so the reason for such calls is a mistery. Anyhow, compiling the code against librsvg-2.42.1 solved the issue.

Regarding the camberra module, I still have to figure out how to make it work properly…

Thanks!


(Morgan Hardwood) #42

@Carmelo_DrRaw yes, RT does not (or should not) use any SVGs. We do use SVGs as the source, but generate PNGs from them and only use the PNGs in the UI. I grepped the UI source files and found no instances of an SVG being loaded.

I will try valgrind tonight. The last time I ran it, it was on an i7 quad-core and it took forever. Now I’m on a 2-core 0.9GHz…


(Carmelo Dr Raw) #43

That’s one of the reasons to have the separate callgrind_control commands, to switch on the instructions analysis only when needed. This not only provides an analysis limited to the critical part of the execution, but also makes the rest run faster…