[RC3] Composition mode performance issue

Scrolling text while in composition mode lags A LOT. See attachment for CPU measurament while scrolling.

It doesn’t seem related to the amount of text (just 700 words) but to the amount of notes attached to the text, because another document with 1400 words (and no notes) scrolls just fine. It’s just a blind guess.

Also, the typing of the text becomes a pain, laggy as hell.

It is a known case that documents with many comments or inspector footnotes cause delays, not just in composition mode. See other threads here.



Four notes are not that much :smiley:

However, could the performance issue related to touchscreen devices? Scrolling and editing in composition mode seems fine, unless on a touch-enabled device.

I don’t know why that would be, except the Windows drivers for them might not have the best settings for Scrivener? I think Scrivener doesn’t mess with devices itself, deferring to Windows for those functions. (mouse, keyboard, etc)

It doesn’t need to have anything to do with drivers. Scrivener could have an event handler firing only when something behind the lines like a “IsTouchEnabled” property equals to true, and such handler could have poorly implemented code that wastes tons of CPU time.

That’s my blind guessing, though, because I cannot think anything else causing such poor performance. Any other app on such device (photoediting, developer-oriented, videogames, etc…) run smoothly. Why on earth a text editing app would lag while scrolling or editing a text made of few thousand words?

Also, Word let me scroll a document of 600+ pages and 800 notes without any problem at all on the very same machine.

Last, but not least, the performance is degraded in composition mode only (or noticeable enough). That’s a code smell.

RC5 and performances of Composition mode are still awful on my Surface (touch-capable) device.

RC6 and composition mode is still unusable on my Surface. It consumes tons of CPU (about 40%) making it laggy as hell. Closing composition, CPU turns back to normal and Scrivener is fast as usual.

Is there any log/info I can share to help you fix this? It’s REALLY annoying, since traveling and writing (on my Surface) is a pretty common scenario in my case.

Any chance you could give a few more details of your system (e.g. processor type, speed; how much RAM, etc.?) I have a desktop with a Core i7-6700, 3.4ghz, 16GB of RAM and am not seeing what you describe at all (CPU utilisation doesn’t go above 10% even with a series of documents in Scrivenings mode open in the composition mode).

Maybe the touchscreen drivers? I don’t have a Surface any more, but I notice Microsoft keep doing updated drivers and firmware for them. So perhaps that’s worth checking (if you haven’t already, obviously).

Tested this out on my Surface Pro and did not have the issue either. Here is what I have hardware and OS-wise:

Just a small 256GB SSD to hold things. I occasionally have choppy scrolling when using my fingers to do so, but prefer to use an external mouse or the stylus - the stylus seems to track better than the finger method. I also noticed that changing the screen resolution and scaling percentage affects the precision of the touch screen. YMMV.

Yeah, composition mode runs fine on my touch-enabled Lenovo ThinkPad X1 Yoga gen3, for any of the RC versions. My system specs are identical to Jestar’s, except I’m running Win10 Pro.

Documents with lots of comments take longer to load into the editor, but also run fine in composition mode.


My specs are pretty similar to yours, except I have 16 GB of RAM (can’t remember the specific CPU model atm, but it’s a i5 for sure).

I’m really puzzled about the awful performances in this case. Everything is fine (CPU at 8% in Idle) and then it rockets to sky high (around 20/40%) the whole time I’m in Composition mode. It’s not something related to scrolling only. Typing also gets sluggish performances.

At this point, it could be something related to drivers… Funny thing is, games and other apps runs fine. What on earth could Scrivener request to my hardware to cause such trouble on my config? :smiley:

At rest, no Scrivener project(s) open, I have less than 2% CPU though my RAM is hovering at ~80% usage (includes MS Teams and VPN software running in background/standby mode). It is interesting to note that opening Scrivener only gives a slight blip to RAM usage that almost immediately goes away (well, back to normal of 80%) and the CPU rises only slightly on average - quick blips then back to the baseline. Looking at the process monitor shows Scrivener’s maximum CPU utilization only goes up to about 3% total - and I have to work at it to do that by opening and closing menus and switching rapidly between various views. I’ve never been able to get above that 3% mark for average CPU usage. Just all sorts of weirdness with the Surface Pro.

Looks like I might have found the source of performance degradation.

I have a background image set in composition mode and usually a little bit of paper fading. Removing it completely (setting the paper to have no transparency at all) seems to greatly improve the overall performance. (still a little bit sluggish, but bearable somehow)

To devs: could you guys take a look at this? We all know opacity it’s quite expensive, but seems a little bit too much in this case. Again, on the very same hardware, I can play many hi-res 2D games without any fps drop. Maybe there is some piece of code consuming way too much resources?

I’m so picky because I’m a programmer myself by day, so please excuse my pressure on this subject :smiley:

It seems this forum has more developers than writers. :slight_smile:

Games use OpenGL, DirectX and other suitable technologies. Scrivener is not using these.
Try hiding the main Window via the Options setting and test if it helps. You can also try using a smaller image in size as a Composite background.

Well, it turns out that doing a clean install of the Intel HD drivers fixed everything. Composition mode it’s working pretty good now.

I’m glad about this, but curious about the hows and whys. :smiley:

I guess we’ll never know.