Bug 462209 - kwrite doesn't repaint for a moment after opening, and the contents are offset to below
Summary: kwrite doesn't repaint for a moment after opening, and the contents are offse...
Status: RESOLVED WORKSFORME
Alias: None
Product: kate
Classification: Applications
Component: kwrite (show other bugs)
Version: Git
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-24 17:26 UTC by FeepingCreature
Modified: 2024-04-08 03:47 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
kwrite 22.11 behavior (854.80 KB, image/png)
2022-11-24 17:26 UTC, FeepingCreature
Details
kwrite 4e48383ea behavior (849.51 KB, image/png)
2022-11-24 17:28 UTC, FeepingCreature
Details

Note You need to log in before you can comment on or make changes to this bug.
Description FeepingCreature 2022-11-24 17:26:24 UTC
Created attachment 153996 [details]
kwrite 22.11 behavior

I tried upgrading to master (4e48383ea) because on Ubuntu 22.10, stock kwrite does not save the window size on exit. However, for a moment after opening 4e48383ea, the kwrite window is unpainted, containing whatever was underneath the window as it opened. Now, this was always the case, but it wasn't annoying because the contents were at the same position, meaning it looked like the frame was drawn first, then the text. However, on 4e48383ea, the unpainted contents are *offset* relative to the window beneath, and last longer. This makes them visually far more distracting. I built v22.11.80 to compare, and the issue does not happen there.

Does the window get moved after opening? Or does it have to do with the tab rewrite?

STEPS TO REPRODUCE
1. Open kwrite
2. Observe offset version of the desktop below, displayed for ~250ms.

EXPECTED RESULT

kwrite should delay showing a window at all until the tab is sufficiently loaded to be displayed immediately. Alternatively, it should figure out how to go back to the unoffensive prior look where the contents of the kwrite window were aligned with the window beneath.

SOFTWARE/OS VERSIONS
KDE Frameworks Version:  5.98.0
Qt Version: 5.15.6

ADDITIONAL INFORMATION

Screenshots of before/after attached. Note that the empty outline was visible for 2 frames on 22.11, but 16 frames on 4e48383ea, both built from git.
Comment 1 FeepingCreature 2022-11-24 17:28:01 UTC
Created attachment 153997 [details]
kwrite 4e48383ea behavior
Comment 2 FeepingCreature 2022-11-24 17:29:19 UTC
To elaborate, the reason this is important to me is that with the offset garbage, to my eyes it looks for a moment like a third of the screen has changed. It's incredibly visually distracting, especially given I open hundreds of kwrite windows over a workday.
Comment 3 FeepingCreature 2022-11-30 08:58:16 UTC
This issue also appears on v22.11.90 and the 22.12 branch.

git bisect reduces it to 4011ec9e7a1f770cb0a7271abdb2a8e5c905c47a, "avoid all session restore/save work for KWrite". Indeed, reverting that commit makes this problem go away.

It's unclear why restoring or not restoring sidebars should have this effect.
Comment 4 FeepingCreature 2023-04-24 06:41:32 UTC
Issue still exists on 23.04. (Reverting that commit still fixes it.)
Comment 5 Christoph Cullmann 2024-02-18 19:46:36 UTC
Does that still happen for you?
Comment 6 FeepingCreature 2024-02-18 20:09:16 UTC
Hard to reproduce at the moment, because kate master needs KF6 and I'm still on KF5. I can confirm it still happens with 23.08.4 at least. - Or rather, *something* happens that involves pretty bad flickering and a copy of the top left screen corner, at least on X11. It's easy to see in OBS.
Comment 7 Christoph Cullmann 2024-02-18 20:51:05 UTC
Hmmm, ok, strange, no idea why that commit shall still break it.
Comment 8 FeepingCreature 2024-02-19 07:49:14 UTC
Fwiw, it doesn't happen with kate, apparently, so I just configured my kate to look like kwrite by turning everything off and using an alias that calls it with `-n`. I don't know how big the difference between kate and kwrite's startup is at this point.

I'll retest once I'm on KDE6.
Comment 9 Christoph Cullmann 2024-03-09 19:51:24 UTC
Ok, please re-open if that still happens for the Qt 6 version. Thanks!
Comment 10 Bug Janitor Service 2024-03-24 03:46:17 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 11 Bug Janitor Service 2024-04-08 03:47:41 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!