Description: The latency while scrolling with OpenGL enabled is a bit to high. It makes the scrolling experience less responsive. It's OK, but scrolling isn't that snappy. It's quite obvious when comparing with GDI rendering Steps to Reproduce: 1. Open attachment 136841 [details] 2. Set view to multi-page view 3. Zoom out to 5 pages 4. Scroll up and down with the scroll wheel (and/or page up and down) Actual Results: There is a noticeable latency Expected Results: Less latency would be nice Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.0.0.0.alpha1+ Build ID: 06cad1a9a42ea74434f9ed0e4027163d029eb4a1 CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2017-11-02_23:40:06 Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 137522 [details] Bibisect log Bisected to: author Michael Meeks <michael.meeks@collabora.com> 2015-11-13 12:00:59 (GMT) committer Michael Meeks <michael.meeks@collabora.com> 2015-12-11 11:39:55 (GMT) commit 7bc1f1285e82982b5d900f54f3c6f877517598b8 (patch) tree f055198ff7acfa3cf2fac695186452530d539f19 parent 93185f720aab0e58564c050ea3518746d8597803 (diff) tdf#93529 - move to a Mac-like double-buffered OpenGL model. This moves us to always rendering to an off-screen texture, and then (at idle) blitting this to the screen & swapping buffers. Ideally we should never see any rendering, or flicker again with this approach. Several fixes are included: + avoid multiple OpenGL contexts being created for the same window, created excessive flicker problems. + de-virtualize UseContext - which context we use is less critical. + kill 'mbOffscreen' distinction - all VCL rendering is offscreen. + implement 'doFlush' and high priority idle flushing. + bind stencil buffer for clipping vs. textures - fixing complex clopping when rendering to virtual-devices, and off-screen. + document environment. variables. + use white as default background glClear color, but red or random color for DBGUTIL. Based on using Page Down (the buffering can be noticed)
So what if OpenGL lags a little, as cross platform it is moving performance forward onto accelerated hardware in a reasonably consistent fashion. I don't think it is fair to compaare OpenGL to legacy GDI/GDI+ with all its warts. For more meaningful performance gains on Windows builds we would have to implement native DirectX 11 with Direct2D, DirectDraw even DirectCompute, and also support WDDM driver features. It would make the GUI more stable and perform better, but is way out of scope. Obviously that is not going to happen. So IMHO => NAB
Double buffering with OpenGL commit for bibisect comment 1 went in at 5.1.0.1. In fact lack of double buffering continues to plague default rendering, e.g. bug 105863 or bug 112889
I'm only the messenger; don't take it personally.. I'm only trying to make aware about less snappy scrolling behaviour. I reported this because it would bug me as user, when using LibreOffice in OpenGL mode. They problem is that every performance loss is noticeable, because they rendering is - in my experience on Windows - slowish in general. Even before the identified commit. Sometimes I wonder why OpenGL - when available - should be the default on Windows anyway. They performance isn't great. Only a few people at the bug tracker have OpenGL available. It's consuming limited resources.... Setting GDI/GDI+ to default for the time being, dropping the 'active' support for OpenGL, and focus more on accelerated hardware seems a logical conclusion (to me)
(In reply to Telesto from comment #4) > > Setting GDI/GDI+ to default for the time being, dropping the 'active' > support for OpenGL, and focus more on accelerated hardware seems a logical > conclusion (to me) The route for hardware accelerating Windows builds would be through native DirectX and DirectWrite _not GDI+_ or legacy Uniscribe. The truth is, legacy GDI+ and GDI native implementation is becoming more unmaintainable as Microsoft moves the platform away from it. But cross-platform we've moved to HarfBuzz, and are looking at Freetype, with some skia support, as replacements for DirectWrite rendering on Windows. Similar choices in non-native implementations for macOS Quartz have been made. Its all pretty messy--but resources of the project prevent doing "native" development for the supported platforms. What can be done for the project is OpenGL implementation based.
Yep, I think without an identified target in the code, we can't keep this open. Closing.
Created attachment 137812 [details] Example file To keep this (nota) bug 'complete', a different, more regular document issue: 1. Open the attached file 2. Select the vertical scroll bar, left click & hold, scroll up and down. Scrolling behavior isn't that great in LibO6