Head's up for those that build Sigil from source - Page 2

KevinH · 10-09-2026, 01:10 PM

FWIW, polyfilling with jpg instead of png made a huge improvement in loading speed in Preview for the jxl images, especially the huge second one. No more spinning disk symbol.

BeckyEbook · 10-09-2026, 01:19 PM

I can confirm that images now load faster in the Preview window.

DiapDealer · 10-09-2026, 01:27 PM

They're not loading faster for me. Somehow converting to jpegs instead of pngs has made things worse on my Windows laptop. I can count the seconds before anything renders in Preview. Even the avifs (in @DNSB's test epub) are loading slower than they were previously.

EDIT: My bad. The jxls are still a little slow. It is the avifs that are now terribly slow. I've made sure all debugging/logging is off, but I can't see anything in the last two commits that would cause things to slow down further on avifs.

KevinH · 10-09-2026, 01:47 PM

Wow, I am seeing the exact opposite.

I checked the file sizes and for DNSB's second jxl when converted to jpeg at 95% quality level, the polypill file is much much smaller than the polyfill png ever was. So it should be much faster.

And there should be no way the polyfill is having any impact on the avif images as they load the normal way in URLSchemeHandler with just direct file read and write.

At least that is true in theory!

DiapDealer · 10-09-2026, 02:09 PM

I'm still trying to figure out what's going on. I just know that things weren't loading this slowly on the machine before lunch. Now they are (with a different build).

For the record: @DNSB's latest test build (linked to here: https://www.mobileread.com/forums/sh...65&postcount=5) does not include the new plugins.

KevinH · 10-09-2026, 02:21 PM

There were two changes, the first can only impact how gumbo is used to detect if an image is used, but that only happens in Delete Unused Images.

That just leaves the second change. So you could try hand reverting this change in URLSchemeHandler.cpp to see if the old behaviour comes back.

https://github.com/Sigil-Ebook/Sigil...b858069abfc99b

But nothing here should impact avif loading in Preview at all.

KevinH · 10-09-2026, 02:24 PM

You can directly compare direct loading speed used in ImageTab to QtWebEngine polyfill loading speed using View Image.

DNSB · 10-09-2026, 02:27 PM

Quote:

Originally Posted by DiapDealer

I'm still trying to figure out what's going on. I just know that things weren't loading this slowly on the machine before lunch. Now they are (with a different build).

For the record: @DNSB's latest test build (linked to here: https://www.mobileread.com/forums/sh...65&postcount=5) does not include the new plugins.

That build will be updated in about 8 minutes—started the compile about 6 minutes ago. It'll be interesting to see the timing differences. The old build when opening the svg wrapped XHTML takes about 3 seconds to open the .jxl images and 2 seconds to open the .avif images. Oddly, the image preview has no noticeable delay.

Edit: The new build is now available. The SVG preview now takes about 1 second for the .jxl images while the time for the .avif seems to be about the same. Delete Unused Media Files now reports no unused files to delete.

DiapDealer · 10-09-2026, 02:38 PM

Quote:

Originally Posted by KevinH

There were two changes, the first can only impact how gumbo is used to detect if an image is used, but that only happens in Delete Unused Images.

That just leaves the second change. So you could try hand reverting this change in URLSchemeHandler.cpp to see if the old behaviour comes back.

https://github.com/Sigil-Ebook/Sigil...b858069abfc99b

But nothing here should impact avif loading in Preview at all.

I'll have to wait until later. I'm limited to builds that I can trigger through github's CI right now.

DiapDealer · 10-09-2026, 02:53 PM

It seems like it's working fairly well for others on Windows, so it may just be something to do with this old machine (though I know it was working better earlier). Right now, when I click on one of the xhtml files in DNSB's epub with an avif file, the progress bar quickly goes to 100%, but then it can be upward of 5-6 seconds before the image actually renders. And then it renders all at once. Not like the jxl files that render just a tiny bit progressively.

DNSB · 10-09-2026, 03:05 PM

Could you try my build from the link in the first message in Downloading Sigil test builds for Windows thread and see how it behaves for you?

DiapDealer · 10-09-2026, 03:10 PM

Quote:

Originally Posted by DNSB

Could you try my build from the link in the first message in Downloading Sigil test builds for Windows thread and see how it behaves for you?

I already did. It's no different. I'll wait until I get home to try it on a newer machine (and one of my QEMU VMs).

KevinH · 10-09-2026, 04:26 PM

FWIW, I can see the slowness of the QtWebEngine load of avif on my old intel Mac as well.

On a lark, I changed URLSchemeHandler to polyfill avif with jpeg at 95% and Preview now loads a bit faster than it did before.

Still not fast but there is something very very slow in the Chrome 140 decoding of avif files. Our own qt plugin does it faster.

I did not push this change because it should not be needed. Native loading of an avif file in QtWebEngine is just very slow. I wonder if anyone upstream at Qt has noticed this?

KevinH · 10-09-2026, 04:51 PM

For what it is worth, we may be overreacting to the slowness of avif. According to some web stats the average avif file is only 50 to 500kb in size. Ours compressed is about 5 meg in size and the image is bigger than my desktop monitor.

We should probably be testing it with typical avif files found on the web.

KevinH · 10-09-2026, 04:53 PM

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.

10-09-2026, 01:27 PM	#18
DiapDealer Grand Sorcerer Posts: 29,825 Karma: 212614993 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	They're not loading faster for me. Somehow converting to jpegs instead of pngs has made things worse on my Windows laptop. I can count the seconds before anything renders in Preview. Even the avifs (in @DNSB's test epub) are loading slower than they were previously. EDIT: My bad. The jxls are still a little slow. It is the avifs that are now terribly slow. I've made sure all debugging/logging is off, but I can't see anything in the last two commits that would cause things to slow down further on avifs. Last edited by DiapDealer; 10-09-2026 at 01:57 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Head's up for those who build their own.	KevinH	Sigil	13	08-07-2026 09:32 AM
[help] How can I build the Kindle firmware source code?	BlueFalconHD	Kindle Developer's Corner	2	01-02-2023 05:59 PM
Sigil output with no html or head elements	pittendrigh	Sigil	10	08-25-2018 08:58 AM
Sigil messing up Head	tetrault	Sigil	8	08-05-2016 12:10 AM
pristine build from git HEAD is broken	eschwartz	Calibre	2	05-03-2016 01:34 AM

10-09-2026, 01:10 PM	#16
KevinH Sigil Developer Posts: 10,136 Karma: 7640000 Join Date: Nov 2009 Device: many	FWIW, polyfilling with jpg instead of png made a huge improvement in loading speed in Preview for the jxl images, especially the huge second one. No more spinning disk symbol.

10-09-2026, 01:19 PM	#17
BeckyEbook Wizard Posts: 1,069 Karma: 3999999 Join Date: Jan 2017 Location: Poland Device: Various	I can confirm that images now load faster in the Preview window.

10-09-2026, 01:47 PM	#19
KevinH Sigil Developer Posts: 10,136 Karma: 7640000 Join Date: Nov 2009 Device: many	Wow, I am seeing the exact opposite. I checked the file sizes and for DNSB's second jxl when converted to jpeg at 95% quality level, the polypill file is much much smaller than the polyfill png ever was. So it should be much faster. And there should be no way the polyfill is having any impact on the avif images as they load the normal way in URLSchemeHandler with just direct file read and write. At least that is true in theory!

10-09-2026, 02:09 PM	#20
DiapDealer Grand Sorcerer Posts: 29,825 Karma: 212614993 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I'm still trying to figure out what's going on. I just know that things weren't loading this slowly on the machine before lunch. Now they are (with a different build). For the record: @DNSB's latest test build (linked to here: https://www.mobileread.com/forums/sh...65&postcount=5) does not include the new plugins.

10-09-2026, 02:21 PM	#21
KevinH Sigil Developer Posts: 10,136 Karma: 7640000 Join Date: Nov 2009 Device: many	There were two changes, the first can only impact how gumbo is used to detect if an image is used, but that only happens in Delete Unused Images. That just leaves the second change. So you could try hand reverting this change in URLSchemeHandler.cpp to see if the old behaviour comes back. https://github.com/Sigil-Ebook/Sigil...b858069abfc99b But nothing here should impact avif loading in Preview at all.

10-09-2026, 02:24 PM	#22
KevinH Sigil Developer Posts: 10,136 Karma: 7640000 Join Date: Nov 2009 Device: many	You can directly compare direct loading speed used in ImageTab to QtWebEngine polyfill loading speed using View Image.

10-09-2026, 02:53 PM	#25
DiapDealer Grand Sorcerer Posts: 29,825 Karma: 212614993 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	It seems like it's working fairly well for others on Windows, so it may just be something to do with this old machine (though I know it was working better earlier). Right now, when I click on one of the xhtml files in DNSB's epub with an avif file, the progress bar quickly goes to 100%, but then it can be upward of 5-6 seconds before the image actually renders. And then it renders all at once. Not like the jxl files that render just a tiny bit progressively.

10-09-2026, 03:05 PM	#26
DNSB Bibliophagist Posts: 55,029 Karma: 182340534 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	Could you try my build from the link in the first message in Downloading Sigil test builds for Windows thread and see how it behaves for you?

10-09-2026, 04:26 PM	#28
KevinH Sigil Developer Posts: 10,136 Karma: 7640000 Join Date: Nov 2009 Device: many	FWIW, I can see the slowness of the QtWebEngine load of avif on my old intel Mac as well. On a lark, I changed URLSchemeHandler to polyfill avif with jpeg at 95% and Preview now loads a bit faster than it did before. Still not fast but there is something very very slow in the Chrome 140 decoding of avif files. Our own qt plugin does it faster. I did not push this change because it should not be needed. Native loading of an avif file in QtWebEngine is just very slow. I wonder if anyone upstream at Qt has noticed this?

10-09-2026, 04:51 PM	#29
KevinH Sigil Developer Posts: 10,136 Karma: 7640000 Join Date: Nov 2009 Device: many	For what it is worth, we may be overreacting to the slowness of avif. According to some web stats the average avif file is only 50 to 500kb in size. Ours compressed is about 5 meg in size and the image is bigger than my desktop monitor. We should probably be testing it with typical avif files found on the web.

10-09-2026, 04:53 PM	#30
KevinH Sigil Developer Posts: 10,136 Karma: 7640000 Join Date: Nov 2009 Device: many	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.