Bug 121353 - Rendering with OpenGL slow
Summary: Rendering with OpenGL slow
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.1.3.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2018-11-11 14:52 UTC by szqecs
Modified: 2020-08-28 14:07 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Issue spreadsheet–Foreign visitors in Taiwan (35.07 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-11-11 23:36 UTC, szqecs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description szqecs 2018-11-11 14:52:35 UTC
Description:
Rendering with OpenGL is slow for most GPUs on Windows. Please have it disabled by default.

Steps to Reproduce:
1. Install an Nvidia GPU and Windows 10
2. Enable rendering with OpenGL
3. Open a spreadsheet and zoom it and out

Actual Results:
Lag

Expected Results:
Not lag


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Have rendering with OpenGL disabled by default on the Windows version.
Comment 1 V Stuart Foote 2018-11-11 19:34:29 UTC
Hmm, is this even a valid claim?  It does not appear to be on Windows 10 with Intel HD Graphics 620 (24.20.100.6229) and LO
Version: 6.1.3.2 (x64)
Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
Locale: en-US (en_US); Calc: CL

While true that rendering mode has affected UI performance, e.g. see also bug 113347, Zoom of an empty calc sheet is not affected by rendering mode. 

And font rendering with OpenGL vs. Default (CPU only, or HA) has received additional refactoring for master/6.2

Simple test document of filling 500 rows of a sheet with random numbers zooms smoothly with either Default rendering or OpenGL rendering.

And, as OpenGL is already disabled for GPUs by black list, or on functional failure.

Disabling by default for all Windows builds is simply not merited.

IMHO => WF
Comment 2 Pierre C 2018-11-11 19:57:37 UTC
Confirming. LO 6.0.7.3 I have been forced to diasabeled OpenGL to have correct perfs. Writer
Comment 3 szqecs 2018-11-11 23:36:14 UTC
Created attachment 146543 [details]
Issue spreadsheet–Foreign visitors in Taiwan
Comment 4 szqecs 2018-11-11 23:36:47 UTC
Not empty sheet, this one.
Comment 5 V Stuart Foote 2018-11-12 01:06:24 UTC
(In reply to szqecs from comment #4)
> Not empty sheet, this one.

And again no issues on a system with *functional* OpenGL driver support:
Windows 10 Home 64-bit (1803) en-US with Intel HD Graphics 620, driver 24.20.100.6229

Version: 6.1.3.2 (x64)
Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
Locale: en-US (en_US); Calc: CL

nor with 

Version: 6.2.0.0.alpha1+ (x64)
Build ID: afbfe42e63cdba1a18c292d7eb4875009b0f19c0
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-10_23:59:43
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

GPUs with marginal driver support can be, and should be, Blacklisted--and users unhappy with OpenGL support in their UI are welcome to disable the support.

To that end anyone claiming poor OpenGL performance does need to provide GPU and driver details...

Otherwise => WF, OpenGL enabled for Windows builds is appropriate, disabling it (beyond Blacklist provisions) is IMHO counterproductive.
Comment 6 Aron Budea 2018-11-12 01:28:51 UTC
I can confirm that zooming in the attached spreadsheet using Ctrl + mousewheel stutters with OpenGL enabled. The stutter is gone with OpenGL disabled. Perhaps the same as bug 94682?
Comment 7 Xisco Faulí 2018-12-13 11:46:51 UTC
(In reply to Aron Budea from comment #6)
> I can confirm that zooming in the attached spreadsheet using Ctrl +
> mousewheel stutters with OpenGL enabled. The stutter is gone with OpenGL
> disabled. Perhaps the same as bug 94682?

SEtting to NEW for the time being...
Comment 8 Buovjaga 2020-08-28 12:20:30 UTC
As Skia with Vulkan will replace OpenGL UI rendering on all platforms, it does not make sense to keep OpenGL UI reports open.

Details about Skia: https://www.collaboraoffice.com/success-story/implementing-vulkan-capable-libreoffice-user-interface-using-the-skia-library/
Comment 9 Telesto 2020-08-28 13:55:40 UTC
Fine with
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 6640d7f405d2970ba2825a9455926cc803284d01
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 10 Buovjaga 2020-08-28 14:07:33 UTC
(In reply to Telesto from comment #9)
> Fine with
> Version: 7.1.0.0.alpha0+ (x64)
> Build ID: 6640d7f405d2970ba2825a9455926cc803284d01
> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
> Locale: nl-NL (nl_NL); UI: en-US
> Calc: CL

Wrong backend, if wanting to compare GPU - use Skia/Vulkan. But if problems are seen, new reports should always be created.