PSA: Cursor blink can cause frame jitter/shudder/jank in *other* applications

[follower]

I want to start by mentioning that I've been meaning to say something to all Lapce contributors for a while now:

Thank you.

The existence of Lapce has had a significant positive impact on my ability to learn & use Rust--which, as a language, I feel needs an "IDE" to learn effectively--since I started using Lapce version v0.0.11.

(Which I had to manually patchelf for it to run on my Ubuntu 18.04 LTS-based system--thanks for recently changing to build on ubuntu-1804 rather than ubuntu-latest! :D )

It hasn't always been plain sailing :D but the LSP integration with Lapce has consistently improved with each release & has been significantly better than any of the editor/IDE options I've tried.

And it is important to me that Lapce is a true community Open Source project & not a corporate KPI-focused predatory wolf in sheep's clothing.

So, again, thank you.

In other news...

Oh, yeah, so, I just discovered after many hours debugging during development of my Rusty Game Jam 2 entry that unfortunately in certain situations the recently added Lapce cursor blink can apparenly cause (in my case) Vulkan applications (such as, say, a game made with the Bevy game engine *cough* :D ) to, like, just...

...jitter animations totally-the-f'rame-rate up!

(While the applications in question claim to be getting 60FPS the majority of the time.)

Hoping to provide more detail in a bit but wanted to at least write this much--while still on the post-jam submission adrenaline burst--and get this issue on your radar so fewer other people might get caught out by it.

P.S. Did I mention how much I appreciate the work put into Lapce? :D

[follower]

Some breadcrumbs from research so far (which I'll endeavour to update over time):

• Key code areas:

  • lapce/lapce-ui/src/editor/view.rs

    Line 566 in fc9eabd

    ctx.request_paint();

  • lapce/lapce-ui/src/editor/view.rs

    Line 792 in fc9eabd

    ctx.request_paint();

  • lapce/lapce-ui/src/editor.rs

    Lines 1933 to 1943 in 49f4721

    	let is_focused = is_focused
    	&& (data
    	.editor
    	.last_cursor_instant
    	.borrow()
    	.elapsed()
    	.as_millis()
    	/ 500)
    	% 2
    	== 0;
    	self.paint_content(&data, ctx, is_focused, env);

• Platform:
  • Elementary 5.1 (Linux 5.4.0-117-generic #132~18.04.1-Ubuntu x86_64 GNU/Linux)
  • Nvidia (GK106) GeForce GTX 650 Ti (NVRM: loading NVIDIA UNIX x86_64 Kernel Module 470.129.06 Thu May 12 22:52:02 UTC 2022)
• Possible underlying cause: Unintended negative interactions with Mutter/compositor, OpenGL, frequent flushes & lack of vsync (V-Sync).

[follower]

Oh, forgot the all important workaround:

• Use cargo run from within the Lapse terminal!

This works because shifting the focus to the terminal stops the editor view, git commit view & other cursors from blinking! (And, fortunately, the terminal cursor doesn't blink[0].)

You do need to be careful not to output too much in the way of logs to terminal though or that will lead to a similar level of jitter effect.

[0] And the arrow keys/readline shortcuts actually work in the terminal these days. :)

[follower]

After many more hours researching & troubleshooting I discovered another workaround that shows significant improvement:

• Set GTK_CSD=0 before starting Lapce. This prevents GTK and/or Mutter from trying to use Cairo & OpenGL to render the entire window--including Client Side window Decorations (e.g. title bar, shadoes)--with OpenGL.

In my specific case there appears to be an underlying Nvidia driver issue that is one of the influencing factors.

Lapce changes to consider

• Provide a setting for disabling cursor blink for situations like this or when people want to prioritize battery life.
• Don't blink the cursor when the application is not focused.
• Don't blink the cursor when there has been no interaction from the person using Lapce for a period of time.
• Re-evaluate whether the GTK GLArea class is beneficial in an entirely OpenGL rendered situation or whether moving to e.g. a "foreign" pure OpenGL window would be better--e.g. this provides an option for V-Sync.