Description: We upgraded from LO 24.8.4 to LO 25.8.3 and are using X11 thin clients and SAL_USE_VCLPLUGIN=gen. This means many copies of LibreOffice are running on a large server and being displayed on remote X displays on separate workstations/users... The WYSIWYG font listing pull-down used to work great, it would quickly list all the fonts, user could see what they look like, page/scroll, and select a font. Now it is unusably slow (like 50 to 100 times slower). I put a network trace on and it is consuming the entire workstation's 1Gb/s network connection with any activity in that fontbox, almost continuously. It will also do this some with SAL_USE_VCLPLUGIN=gtk3 as well (it is quite slow but nowhere near as bad; unfortunately we can't use gtk3 VCL for other reasons). The only workaround we have found is to go into expert config and turn off ShowFontBoxWYSIWYG. But this leaves users with no way to choose fonts by seeing a preview "catalog", which is a huge loss/regression for them. Steps to Reproduce: Use a thin client or remote X11 connection and export SAL_USE_VCLPLUGIN=gen Actual Results: Pull-down font list is unusably slow and lagging, even at Gigabit connection speeds. Expected Results: Pull-down font list should be fast and responsive. Reproducible: Always User Profile Reset: No Additional Info: Seeking assistance with this issue.
I can confirm that this behavior affects 25.8.4, but didn't affect 25.2.7.2. I'll confirm it as NEW. For those of us who use LO over ssh, it's a pretty nasty regression. To test, I used * ssh -X workstation * SAL_USE_VCLPLUGIN=gen libreoffice * new writer doc * click on font selection box * scrolled up and down in font list Under 25.2, the box redraws real-time over ssh with X11 forwarding. In 25.8, it causes such a delay that I had to wait a minute or two for my machine to be responsive again.
(In reply to tmacalp from comment #1) > I can confirm that this behavior affects 25.8.4, but didn't affect 25.2.7.2. > I'll confirm it as NEW. > ... > Under 25.2, the box redraws real-time over ssh with X11 forwarding. In > 25.8, it causes such a delay that I had to wait a minute or two for my > machine to be responsive again. OK, in this case, this is a regression. Let's ask for a bibisect.
I do not reproduce the problem with the latest LO 26.8 dev master: Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 3a54d9870fa9f59c580c509a2f04dcf04db0116e CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded Also not reproducible for me with official LO 25.8.4.2 release build. Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 12; OS: Linux 6.2; UI render: Skia/Raster; VCL: x11 Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded @crxssi: In "Additional Info:" you have written "Seeking assistance with this issue.". That is not helpful. Please provide details, as I pasted above. You can go to "Help > About" and use the push button near "Version Information" to copy these details. For example, you may see the difference in above platforms: one uses default renderer, and another is using Skia/Raster. @tmacalp: The same applies for confirmation. Please provide details, as discussed. It is required to diagnose the problem.
(In reply to Hossein from comment #3) > I do not reproduce the problem with the latest LO 26.8 dev master: > > For example, you may see the difference in above platforms: one uses default > renderer, and another is using Skia/Raster. > > @tmacalp: > The same applies for confirmation. Please provide details, as discussed. It > is required to diagnose the problem. Broken: Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Working: Version: 25.2.7.2 (X86_64) / LibreOffice Community Build ID: 5cbfd1ab6520636bb5f7b99185aa69bd7456825d CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded I can confirm that if I enable Skia for all rendering, which is not the default, I am unable to reproduce the issue. Working (ssh -X to localhost but using skia): Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 4; OS: Linux 6.8; UI render: Skia/Vulkan; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded So, you probably can't reproduce because you've modified your settings from stock to use Skia. Good catch on the renderer, though. Please see if you can repro after disabling skia.
(In reply to Hossein from comment #3) > I do not reproduce the problem with the latest LO 26.8 dev master: > > Version: 26.8.0.0.alpha0+ (X86_64) > Build ID: 3a54d9870fa9f59c580c509a2f04dcf04db0116e > CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: x11 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: CL threaded > > Also not reproducible for me with official LO 25.8.4.2 release build. > > Version: 25.8.4.2 (X86_64) > Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df > CPU threads: 12; OS: Linux 6.2; UI render: Skia/Raster; VCL: x11 > Locale: de-DE (en_US.UTF-8); UI: en-US > Calc: threaded > > @crxssi: > In "Additional Info:" you have written "Seeking assistance with this > issue.". That is not helpful. Please provide details, as I pasted above. You > can go to "Help > About" and use the push button near "Version Information" > to copy these details. > > For example, you may see the difference in above platforms: one uses default > renderer, and another is using Skia/Raster. Version: 25.8.4.2 (X86_64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 72; OS: Linux 4.18; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded I noticed your test was with Skia on. I have never heard of Skia. By default, that is off on my installation. That option was not there in LO 7.5.7, was there in 24.8.4 and was off and had no issues. I tested turning on Skia and turned the font preview back on and that DID fix the FontBoxWYSIWYG. But now I will have to test lots of other things to see if there are negative effects using Skia. I already found one, many pop-up dialog windows now appear black for split second before showing the contents. The bigger the window, the longer the black can be seen. For example, the Tools> Options window it is quite noticeable. I don't know if I can use Skia in our environment yet but this is a major step forward in discovering what might be happening.
(In reply to crxssi from comment #5) > I tested turning on Skia and turned the font preview back on and that DID > fix the FontBoxWYSIWYG. But now I will have to test lots of other things to > see if there are negative effects using Skia. I already found one, many > pop-up dialog windows now appear black for split second before showing the > contents. The bigger the window, the longer the black can be seen. For > example, the Tools> Options window it is quite noticeable. > > I don't know if I can use Skia in our environment yet but this is a major > step forward in discovering what might be happening. After a few days of testing Skia in real-word (but limited) use, the pre-black for windows/dialogs continues to be annoying, performance is not worse, and only one new issue.... It did "freeze" my local Xserver twice. Once yesterday, and once today. Each was approximately 5 seconds, and happened when I was simply moving a LO window. Literally, the entire Xserver just froze, then released and returned to normal. I have never seen that happen before. I need to get some other people testing it in our environment. Even so, it might be a suitable work-around for some people? I do wish whatever regressed the FontBoxWYSIWYG function in non-Skia was fixed/resolved, since it would mean I could skirt Skia, and guarantee stability and avoid the annoying pre-black-fill of windows.