Head's up for those that build Sigil from source

[DiapDealer]

That's true. I've also seen some reports that claim people go over the top with avif compression. Which apparently can grind a cpu to a halt when decompressing.

[DNSB]

Originally Posted by KevinH

And decoding a 5 meg avif file is highly cpu intensive and painfully slow when single threaded (which is what QtWebEngine does in its QtWebEngine Process).

So we are probably worst casing this.

That was one of the reasons that I choose large files for my test ePub. If it looks good with those files, smaller files should be no problem.

[DiapDealer]

Originally Posted by KevinH

And decoding a 5 meg avif file is highly cpu intensive and painfully slow when single threaded (which is what QtWebEngine does in its QtWebEngine Process).

I thought QtWebEngiineProcess was multi-process. I always end up with a crap-ton of them running.

[KevinH]

I thought their was one one QtWebEngineProcess for every QWebEngineView but I could easily be mistaken.

[DiapDealer]

That could be. I never paid that much attention.

[DNSB]

I tried opening Sigil and 2 QTWebEngine processes started running. I then opened the Preview pane and one QTWebEngine process became active. That was the only instance that showed any activity while I ran through the 8 images in the Preview pane and in the Image viewer. I then killed both QtWebEngineProcess tasks and only 1 reopened when I played with the images.

I did find one item rather amusing. When I looked at the command line options for the 2 QtWebEngine processes, they were rather long. I used PowerShell with 'Get-WmiObject Win32_Process -Filter "ProcessID = PID"'

"C:\Program Files\Sigil\QtWebEngineProcess.exe" --type=renderer --webengine-schemes=sigil:slLCG;qrc:sV --disable-speech-api --touch-events=auto --disable-databases --disable-gpu-compositing --disable-blink-features=EyeDropperAPI,WebOTP --video-capture-use-gpu-memory-buffer --lang=en-CA --device-scale-factor=1.75 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=4 --time-ticks-at-unix-epoch=-1790891843200435 --launch-time-ticks=695139410021 --field-trial-handle=7008,i,1307684628108535388,8511791650392511798,262144 --enable-features=NetworkServiceInProcess2,TracingServiceInProcess --disable-features=Back groundFetch,EyeDropper,InstalledApp,StandardCompliantNonSpecialSchemeURLParsing,WebOTP,Web Payments,WebUSB --variations-seed-version --mojo-platform-channel-handle=7188 /prefetch:1

"C:\Program Files\Sigil\QtWebEngineProcess.exe" --type=renderer --webengine-schemes=sigil:slLCG;qrc:sV --disable-speech-api --touch-events=auto --disable-databases --disable-gpu-compositing --disable-blink-features=EyeDropperAPI,WebOTP --video-capture-use-gpu-memory-buffer --lang=en-CA --device-scale-factor=1.75 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=3 --time-ticks-at-unix-epoch=-1790891843200435 --launch-time-ticks=695139346593 --field-trial-handle=7008,i,1307684628108535388,8511791650392511798,262144 --enable-features=NetworkServiceInProcess2,TracingServiceInProcess --disable-features=Back groundFetch,EyeDropper,InstalledApp,StandardCompliantNonSpecialSchemeURLParsing,WebOTP,Web Payments,WebUSB --variations-seed-version --mojo-platform-channel-handle=7004 /prefetch:1

[DiapDealer]

I honestly think I was originally just so focused on the .jxl workaround, that I simply didn't notice that it was the avifs that were the slow ones all along.

[KevinH]

And, there really isn't much we can do to help avif loading in Preview/QtWebEngine as it is native to Chrome. We can only add support for avif to QImage and that seems to work well.

[DiapDealer]

Agreed. The large avifs load in a couple of seconds on my Windows VM. So I'm not too worried about reasonably sized ones in epubs.

Interestingly enough: it is the jxl files that load slower using the same epub in my Linux AppImage. The two linux qt image plugins were built using an Ubuntu 22.04 docker image (like everything is with the AppImage). They take several seconds on my fairly beefy Linux machine. I may need to do some checking to make sure libqjpegxl6.so is being built with all of the optimizations possible in that docker image (though again... suitably-sized jxl images load fine).

[KevinH]

Is this with the very latest from master? The one the polyfills jxl to jpegs (not pngs).

[DiapDealer]

That's a good question. I know I've pulled the latest changes from master, but I'm not 100% certain I've rebuilt the AppImage since then.

[DiapDealer]

Clearly I had not rebuilt after those changes. Much better now! Reasonable times even with the 15mb epub test case.

[KevinH]

Phew! Glad to hear it!

[DiapDealer]

I'm still a little worried about the Windows build. I had a chance to install a build (latest master) on a fairly beefy Windows 11 machine. It's got a pretty hardcore graphics card and the machine is used to run the latest Microsoft Flight Simulator.

When I opened the 15Mb test epub, it was terribly slow (both jxl and avif) some times they wouldn't render at all. Sometimes they only partially rendered. For whatever reason, disabling hardware acceleration improved the performance quite drastically!

I'm still not too worried with reasonably sized images, but I didn't expect this machine to balk at the big epub this badly.

[KevinH]

Could the Windows build for both avif and jxl plugins be turning off something Windows needs in libjxl or libavif?

It is wild that turning off the gpu acceleration actually speeds things up!