Memory Leak? (v2.31)

[hayaku]

Yeah the clunky behavior/slowdown is in the preview window, not the text editor.

I just did some testing:

With GPU acceleration enabled, Preview window renders at ~60 FPS, with maybe 10ms latency.

With GPU acceleration disabled, Preview window renders at ~21 FPS, with ~100ms latency.

Interestingly, 100ms of latency is about the point where feelings of "sluggishness", "discomfort" and "nausea" can start to kick in, in a major way, at least in academic research done into computational/interactive environments (https://www.frontiersin.org/journals...20.582204/full)

I guess this is why I intuitively switched it off.

I have another computer with a 1080 installed, 8GB VRAM, also AMD. I'll replicate my tests later today.

[hayaku]

Update #2, and just to clarify:

~20fps, 100ms was for a test file, completely blank, except for the words "HELLO" written in 400 separate lines.

When I try loading an actual, working file (no images, just ~100k words of text, broken into ~30x 3k word chapters) I get:

~2fps, ~450ms latency (!!!!!!).

This is unambiguously unusable, whereas the test file was merely uncomfortable.

Hope this helps.

PS—For some reason, my first post went to moderation, but this one was published immediately. So please do not be alarmed if these appear out of order!

[DiapDealer]

I'm not sure how FPS is relevant at all in xhtml rendering. There is no video playing. So there are no "frames" involved at all. Please stick with latency. And if you could provide the method with which you're able to accurately measure Sigil's Preview latency, that would be great too. So we can all compare apples to apples.

But regardless... Preview's supposed latency with hardware acceleration disabled is an entirely separate issue from memory leaks. Can you please confirm that disabling WebEngine's hardware acceleration stops the increasing memory use issue? Then maybe we can figure out why disabling hardware acceleration creates such noticeable latency on your hardware, but not on others'.

Can you also confirm that you have no global Qt environment variables set on your system (perhaps for other Qt programs or games) that could affect Sigil's behavior?

[hayaku]

I'm not sure how FPS is relevant at all in xhtml rendering. There is no video playing. So there are no "frames" involved at all.

I have no idea either, but worth mentioning, right? It's all data at the end of the day. FRAPS registers ~60 FPS with acceleration on, and 1–2 FPS without; and trust me: when anything breaks down to the point where it hits 1 FPS, it tends to interrupt workflow

Also, after doing a little digging, it seems that Qt Web Engine does indeed leverage Open GL/Dirext X in its rendering pipeline, making FRAPS a very ample tool for diagnosing breakdowns in the rendering cycle.


Can you also confirm that you have no global Qt environment variables set on your system

It absolutely does solve the memory leak issues.


Can you also confirm that you have no global Qt environment variables set on your system

I have no idea what this would be, I never even heard of Qt until I came here to report the memory leak. So I suppose can assume, its a no?


And if you could provide the method with which you're able to accurately measure Sigil's Preview latency

I went simple, eyeballed it against "Lag Simulator Delux". The human brain is scarily accurate when it comes to detecting small fluctuations in Proprioceptive Feedback Delay, and one could probably expect a ±10% margin of error using this method, at least according to the current scientific consensus. https://www.skytopia.com/stuff/lag.html

[DiapDealer]

Originally Posted by hayaku

I have no idea either, but worth mentioning, right? It's all data at the end of the day. FRAPS registers ~60 FPS with acceleration on, and 1–2 FPS without; and trust me: when anything breaks down to the point where it hits 1 FPS, it tends to interrupt workflow.

Not really, no. Not all data is relevant. When there are no frames involved (and there are no frames involved in rendering xhtml in a browser), then a frame rate is not relevant.

Originally Posted by hayaku

Also, after doing a little digging, it seems that Qt Web Engine does indeed leverage Open GL/Dirext X in its rendering pipeline, making FRAPS a very ample tool for diagnosing breakdowns in the rendering cycle.

A tool that measures frame rate is not going to be at all useful for diagnosing Sigil's Preview latency. That doesn't change simply because WebEngine can make use of OpenGL/DirextX. Sigil's Preview is not asking WebEngine to leverage OpenGL/DirextX to display anything that could be presented in frames per second (unless an epub happens to contain video--and then proprietry codecs included with Qt kick in). So any measured drop in OpenGL/DirextX's ability to display content that CAN be measured in fps (which is what FRAPS is measuring) is not relevant to Sigil's ability to render text/images in Preview. FPS doesn't matter when there are no frames.

Originally Posted by hayaku

I went simple, eyeballed it against "Lag Simulator Delux". The human brain is scarily accurate when it comes to detecting small fluctuations in Proprioceptive Feedback Delay, and one could probably expect a ±10% margin of error using this method, at least according to the current scientific consensus. https://www.skytopia.com/stuff/lag.html

Sorry. I have no idea what any of that means. But if it means your latency numbers are merely guesses, then I'm not really that interested in pursuing this. Nor am I interested in scientific studies that indicate how well the human eye might be able to guess latency. You gave fairly specific latency numbers that I assumed were able to backed by something other than your ability to make up numbers. If I can't duplicate your tests, I can't work on fixing what might be wrong with Sigil on your system. It's that simple. Your eyeballs are the first human ones to claim to be able to discern a reduction in Sigil's text rendering speed when QtWebEngine's hardware acceleration is disabled. I'll need a larger sampling than 1 if I'm going to dig into the possibility that something needs to be researched in that regard. Sorry.

[hayaku]

Why are you being so rude? I only came here to report a bug.

[KevinH]

He is not being rude. You reported a bug, that can not be duplicated by all others. The bug may be either in Qt (the webengine toolkit used by Sigil) or in your video driver, or just specific to your system.

We then point you at turning off the gpu via Sigil preferences so you can test if the driver or qt may be at fault, but instead of trying that and reporting back whether it fixed the issue for you, all you said is you tried it and then did not like it.

Once pushed for more you came up with a frame rate measure that is effectively meaningless for an epub. Preview is only updated when receiving a signal that something has been edited in the epub or scrolling is needed. And that has its own timer to prevent unnecessary duplicative updates. This is not a video game. Any lag is due to your system io once the signal a scroll or edit has been done and the timer runs out.

When again pushed for more info on how you are measuring frame rate in a meaningful way you then admit it was by eye.

You finally did add that the memory issue went away when you disabled the gpu.

Then you wonder why we are upset?

Please try updating your gpu video driver to the latest version. Qt/Chrome only works for the most recent video graphics cards. That is why we added the Preference to disable its use so that you can continue to use Sigil normally.

[DiapDealer]

Originally Posted by hayaku

Why are you being so rude? I only came here to report a bug.

I'm not being rude. I'm asking for data and you're giving me guesses, irrelevant fps numbers and philosophy.

I, on the other hand, have been using Google's devtools (built into Sigil) to profile the performance of page loading (some large, some small, some text-only, some text with images) and am seeing numbers that are not changing at all between QtWebEngine's hardware acceleration being enabled or disabled.

So disabling QtWebEngine's hardware acceleration is a suitable workaround for the bug you reported for the vast number of people out there. If you'd like us to help figure out why it doesn't help in your case, please stop providing irrelevant numbers and scientific studies that have nothing to do with the problem at hand.

[DiapDealer]

I've done further testing on a total of four machines using the performance feature of Google's devtools (inspector): 3 Windows 10 (one virtual) and one Linux. In none of the tests did the rendering time of any pages increase by disabling QtWebEngine's hardware acceleration. In fact, the rendering time actually decreased on three of the tests! That surprised me. Hardware ranged from my dog-tired i3 Dell laptop, to an 8 core i9 with 64Gb of Ram. All have what I would call very modest video hardware.