Sigil-0.9.13 Released

[BeckyEbook]

Originally Posted by KevinH

Also Becky, what Windows 10 update and exact build are you using?

Windows 10 Pro 1809 (17763.379)
Memory: 16GB

Originally Posted by KevinH

Are you seeing Sigil's memory use growing to over 1 gig from just an hour or so from working with it?

Usually not, because my sessions in Sigil are short. Small corrections, saving the file and closing the program.

But... Sometimes I can call Sigil to consume memory (ascending) and CPU (about 30%). But it may be related to the system itself (Windows) or some application that does not like Sigil. This is not reproductible, which drives me crazy.
Certainly this is not (on my system) related to the anti-virus/firewall program.

BTW – I confirm, that commit (Appveyor 0.9.13-132) fixes the blinking problem of the preview window.

Thanks for fast reaction. I could check this url() myself via QDebug, but the condition seemed correct.

[KevinH]

Glad to hear it works.

I do not think there is a report of the huge memory use on a Windows 10 update 1809 machine with any of the recent builds. All really bad reports seem to be limited to Windows 10 update 1803.

That is good news in that the next full Windows update should happen soon and so may "fix" some of our issues.

[DiapDealer]

Originally Posted by BeckyEbook

I could check this url() myself via QDebug, but the condition seemed correct.

That's where experience with the three different platforms comes into play.

When I see a conditional based on a file-path in area that seems problematic for only one or two platforms of the three supported ... I want to see exactly what that "if" is seeing.

You have figured out how to easily see QDebug output with your own Windows builds, right? I made sure they get written to the file defined by the WINDOWS_SIGIL_DEBUG_LOGFILE environment variable.

[exaltedwombat]

Playing around with different methods of conversion from PDF, I ended up with a Sigil project where each chapter was one long paragraph, split up with styled <br/> objects. This brought Sigil to its knees - it took several seconds to register even a change in cursor position!

Don't know if this is unique to Windows 10 and/or the current Sigil version. And I'm not really complaining!

[brent63]

Originally Posted by KevinH

One interesting test just before you go to bed at night would be to:

Okay I did what you asked except I had my normal setup, so the preview window was open all night (See Attached) with only a 1.5 MB uptick in memory.
(See Attached)

[brent63]

Originally Posted by DiapDealer

Another thing to try is to disable CFG for the Sigil binary.

I did this when you posted it.

[KevinH]

Sigil is a line based editor that uses syntax highlighting. So yes, it would break any line based editor that uses syntax highlighting and this would happen in all versions of Sigil.

You have no lines to syntax highlight, just one huge one!

Mend on Open may help as it introduces line breaks after block tags but I am not sure if a br is a block tag or not. That said doing a Mend and Prettify on first opening is probably the best way to handle that or immediately use a Find and Replace after to add in true line breaks after each br tag.

Then all editing should be back to normal.

[brent63]

Originally Posted by DiapDealer

I think its probably worth a test to see if Sigil exhibits the same extreme performance issues when editing an epub that doesn't embed any fonts. Because I'll be honest: I can see this version of Sigil getting seriously bogged down (on Windows especially) if every single character of the book is being displayed with an embedded font. Using an embedded font for normal body text is simply not done that much these days.

I removed all but one embedded font (Canterbury.OTF) that I use for the drop case. I do however have it looking for Georgia.tff as I really dislike Ariel front.

[KevinH]

So virtually no change from lid closed sleeping overnight. That is what I expected. A process that is actually sleeping and not being constantly awakened should not even experience true memory leaks. And it appears yours did not. From your last screen capture it shows Preview was open. Did you run the test that way?

So lid down sleeping does not appear to affect Sigil. My only worry would be having a system utility run that cleans of flushes files in a temp folder. That bug actually hit Macs that sleep for longer than 3 or 4 days. But the user can work around that by setting their own temp directory.

So it appears that all is well based on that test.

Originally Posted by brent63

Okay I did what you asked except I had my normal setup, so the preview window was open all night (See Attached) with only a 1.5 MB uptick in memory.
(See Attached)

[KevinH]

Originally Posted by brent63

I did this when you posted it.

And have you had huge memory use crashes or long hangs since disabling CFG for Sigil alone?

KevinH

[brent63]

Originally Posted by KevinH

For the record: See this Windows specific bug in Qt that caused some fonts to be detected as italic when not, and other bugs that were italic to be detected as normal:

KevinH

as the report said it affected versions QT 5.11.1, QT 5.12.1 can I assume that Sigil 9.10 is not affected by this?

[BeckyEbook]

Originally Posted by DiapDealer

You have figured out how to easily see QDebug output with your own Windows builds, right? I made sure they get written to the file defined by the WINDOWS_SIGIL_DEBUG_LOGFILE environment variable.

Yes! Very useful. I like it.

[KevinH]

Originally Posted by brent63

as the report said it affected versions QT 5.11.1, QT 5.12.1 can I assume that Sigil 9.10 is not affected by this?

No, I do not think so as this is a long standing windows bug in multiple Qt versions. Calibre has the same issues. There is talk about how some fonts just do not work with Qt.

Hopefully as we are moving to Qt 5.12.2, for our next release, this bug will be fixed.

[brent63]

Originally Posted by KevinH

And have you had huge memory use crashes or long hangs since disabling CFG for Sigil alone?

KevinH

Not sure, have been jumping between chapters and books (9) removing most embedded fonts, cutting and pasting sheetstyles, chapters and find and replace all.

Will see how it goes today.

[DiapDealer]

Originally Posted by brent63

I removed all but one embedded font (Canterbury.OTF) that I use for the drop case. I do however have it looking for Georgia.tff as I really dislike Ariel front.

Would it not be possible to test an epub where absolutely no font-diddling was taking place? That's the only way I'm going to be able to determine if there's a connection.