Bug 99521 - UI Menu problems on multi-monitor system
Summary: UI Menu problems on multi-monitor system
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 120075 127929 (view as bug list)
Depends on:
Blocks: Multimonitor VCL-OpenGL
  Show dependency treegraph
 
Reported: 2016-04-27 02:19 UTC by Richard
Modified: 2020-08-28 12:01 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screen shot of menu being displayed incorrectly on secondary monitor (400.91 KB, image/jpeg)
2016-04-28 18:28 UTC, Richard
Details
opengl_device.log (314 bytes, text/plain)
2016-04-28 22:22 UTC, Richard
Details
Opengl Viewer report (41.94 KB, text/plain)
2016-04-28 23:20 UTC, Richard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard 2016-04-27 02:19:09 UTC
Just installed version 5.1.2.2(x64).  I have a dual monitor system running Win7_64 with a NVidia GeForce GTX560 video card.   When I run "writer" ( noticed this in Calc as well but those are the only two I've tried), if I move the writer window from the primary display (the one with windows task bar) to the secondary display and try to access any menu (either menu bar or popup) the text and graphics within the menu disappear/reappear as I move the mouse over the menu items.  When it disappears, I still see the grey background of the menu but all decorations (text and separators) disappear and it is very hard to stop on a specific menu item to click on it without the text, but if I release mouse button on a specific X/Y location within the menu the function that would normally be displayed at that location IS executed.   So it seems like a painting issue and not a menuitem clicked issue. 

Also if I hover over an item that would create a submenu, the submenu initially displays but when I start moving towards it the submenu does the same thing.

If I move "writer" back to the primary display the problem does not seem to occur.

I recently upgraded my machine from Vista 32bit and version libreoffice 4.1.3 which combination worked on the same hardware.  When still on Vista 32bit I tried version 5.0.5 but had sever display problems on both monitors so I went back to 4.1.3.  I looked around for a 64bit version of Libreoffice 4.1.3 to try on my win7_64 system ( or any 4.x 64bit version) but could not find one to try.

For now I'll only use primary display ( or I may try the 32bit version of 4.1.3)...  Just thought you'd want to know.
Comment 1 tommy27 2016-04-27 05:30:52 UTC
please post a screenshot
Comment 2 V Stuart Foote 2016-04-28 00:08:33 UTC
What was the status of OpenGL rendering on your system?

Tools -> Options -> View: Use OpenGl for all rendering (on restart)

Should probably be disabled given your GPU and Widncows 7 and drivers, but if not the issues described can manifest with OpenGL rendering.


P.S. 64-bit builds for Windows only arrived with the 5.0.0 release.
Comment 3 Richard 2016-04-28 18:28:09 UTC
Created attachment 124704 [details]
Screen shot of menu being displayed incorrectly on secondary monitor
Comment 4 Richard 2016-04-28 18:34:28 UTC
I checked on the state of :
Tools -> Options -> View: Use OpenGl for all rendering (on restart)

Currently it is "checked/selected", if I "uncheck/disable" that option then the menus seem to display correctly (if somewhat more sluggish).

Not sure why this should display fine on the primary monitor and not the secondary since the same GPU would be involved.

But for now I'll just run with with OpenGL disabled.
Comment 5 V Stuart Foote 2016-04-28 18:47:43 UTC
OK then, not unexpected. One last thing before we close this WFM, please post the text from your

C:\Users\<yourusername>\AppData\Roaming\LibreOffice 4\cache\opengl_device.log

we use this information from troubled systems to blacklist non-functioning OpenGL implementations.
Comment 6 Richard 2016-04-28 22:22:33 UTC
Created attachment 124709 [details]
opengl_device.log

Requested opengl_device.log file.
Comment 7 Richard 2016-04-28 22:29:30 UTC
Thanks for your assist...  

Also is there a link to the blacklist so I can check potential cards before I purchase?  Tried searching google (libreoffice opengl blacklist) but all I got were links to other bugs or unrelated items.
Comment 8 V Stuart Foote 2016-04-28 22:45:46 UTC
@Richard,

The driver string is passing the balcklist--which is why 5.1.2.2 is opening for you with OpenGL rendering enabled.

http://opengrok.libreoffice.org/xref/core/vcl/opengl/opengl_blacklist_windows.xml

which cuts off with the nVidia 353.62 driver release. 

You can see we don't currently track GPU/driver combos for black-listing OpenGL support on Windows (its worse on Linux) and just set the threshold by driver.

If you grab the OpenGL Extension Viewer utility from RealTech-VR

http://www.realtech-vr.com/glview/

you can test and post up the summary of just what your GPU/driver pairing support, especially if you are getting 100% 4.4 support on your GTX560 based card.
Comment 9 Richard 2016-04-28 23:20:54 UTC
Created attachment 124710 [details]
Opengl Viewer report

Capture of report information from the OpenGL Extensions viewer. Note that my card is listed as 100% compatible up through 4.4.  The only items listed as not fully compatible are 4.5 (90%) and ARB 2015 (30%).

If there is anything else I can provide let me know....  As a Firmware Engr. myself I know how helpful any "good" :-) information is.
Comment 10 V Stuart Foote 2016-04-28 23:33:36 UTC
Given support level for the GPU/driver mix, to me this is a legitimate bug. 

But testing the mix to confirm could prove a challenge--Windows 7 and a GTX 560 GPU. I've moved my nVidia systems to Windows 8.1 and 10--dual monitor but I don't get the same issue.

Adding to the OpenGL meta issue bug 93529 for visibility, one of the devs working on the numerous OpenGL glitches may get back to you with specific questions.

Meanwhile if you need to use the second monitor, disable OpenGL or just try to stay on the primary display ;-)
Comment 11 QA Administrators 2017-11-26 17:11:32 UTC Comment hidden (obsolete)
Comment 12 Aron Budea 2018-09-26 23:55:56 UTC
*** Bug 120075 has been marked as a duplicate of this bug. ***
Comment 13 QA Administrators 2019-09-27 03:04:38 UTC Comment hidden (obsolete)
Comment 14 Timur 2019-10-07 08:44:32 UTC
*** Bug 127929 has been marked as a duplicate of this bug. ***
Comment 15 Timur 2019-10-07 08:46:51 UTC
Richard, aksrmartin, christine
Please test with daily master LO that is now 6.4+. YOu can get it from https://dev-builds.libreoffice.org/daily/master/. It will not interfere with you stable working LO.
Comment 16 aksrmartin 2019-10-13 18:47:54 UTC
I tried the libo-master64_2019-09-30_09.18.03_LibreOfficeDev_6.4.0.0.alpha0_Win_x64.msi

If OpenGL is selected and the spreadsheet is open in my 2nd monitor,  then the Delete dialog box has no display of controls. They still work, however, when I blindly clicked on where the OK button is. When the spreadsheet is open in my 1st monitor, then the Delete dialog displays controls correctly. 

If OpenGL is not selected, then the Delete dialog shows controls in both monitors.
I am running Windows 10 64 bit with AMD Radeon HD 5700 graphics controller.

Libre office Calc still has a problem with OpenGL. I don't know what OpenOffice Calc uses, exactly, because in thatTools / Options / View menu it doesn't explicitly say "OpenGL". The menu says "Use Hardware Acceleration". Whether I check this or not makes no difference. Of course, it also doesn't display a Delete dialog, so that's probably no real comparison to Libre Office.

Anyway, my test shows a problem with OpenGL and the new Libre Office Calc, same as with older versions of Libre Office.

The contents of my C:\Users\<yourusername>\AppData\Roaming\LibreOffice\ 4\cache\opengl_device.log:

DriverVersion: 15.200.1062.1004
DriverDate: 8-3-2015
DeviceID: PCI\VEN_1002&DEV_68BE&SUBSYS_22871787&REV_00
AdapterVendorID: 0x1002
AdapterDeviceID: 0x68be
AdapterSubsysID: 0x22871787
DeviceKey: System\CurrentControlSet\Control\Video\{FE1EFCE3-D597-4189-9900-A5CE76BF007F}\0000
DeviceString: AMD Radeon HD 5700 Series
Comment 17 V Stuart Foote 2019-10-13 20:48:20 UTC
(In reply to aksrmartin from comment #16)
> I tried the
> libo-master64_2019-09-30_09.18.03_LibreOfficeDev_6.4.0.0.alpha0_Win_x64.msi
> 

Thanks for retesting.

> If OpenGL is selected and the spreadsheet is open in my 2nd monitor,  then
> the Delete dialog box has no display of controls. They still work, however,
> when I blindly clicked on where the OK button is. When the spreadsheet is
> open in my 1st monitor, then the Delete dialog displays controls correctly. 
> 

Even on current GPUs with current Windows 10 WMMD GPU drivers we do get occasional OpenGL rendering glitches--lately around the RenderContext() double buffering. 

> If OpenGL is not selected, then the Delete dialog shows controls in both
> monitors.

Good, the default GDI Hardware Acceleration for the GPU is functioning--you won't have to fall back to even slower CPU only rendering.

> I am running Windows 10 64 bit with AMD Radeon HD 5700 graphics controller.
> 

No current driver support for a Radeon HD 5700, AMD abandoned it as legacy Catalyst device.

> Libre office Calc still has a problem with OpenGL. I don't know what
> OpenOffice Calc uses, exactly, because in thatTools / Options / View menu it
> doesn't explicitly say "OpenGL". The menu says "Use Hardware Acceleration".
> Whether I check this or not makes no difference. Of course, it also doesn't
> display a Delete dialog, so that's probably no real comparison to Libre
> Office.

Apache OpenOffice has not implemented any support for OpenGL.

> 
> Anyway, my test shows a problem with OpenGL and the new Libre Office Calc,
> same as with older versions of Libre Office.
> 
> The contents of my C:\Users\<yourusername>\AppData\Roaming\LibreOffice\
> 4\cache\opengl_device.log:
> 
> DriverVersion: 15.200.1062.1004
> DriverDate: 8-3-2015
> DeviceID: PCI\VEN_1002&DEV_68BE&SUBSYS_22871787&REV_00
> AdapterVendorID: 0x1002
> AdapterDeviceID: 0x68be
> AdapterSubsysID: 0x22871787
> DeviceKey:
> System\CurrentControlSet\Control\Video\{FE1EFCE3-D597-4189-9900-
> A5CE76BF007F}\0000
> DeviceString: AMD Radeon HD 5700 Series

That is old unsupported AMD hardware and their drivers are not going to be the most functional on Windows 10 which with that AMD GPU and driver should probably be black listed. Otherwise if you can't upgrade the Graphics card, might be best to disable OpenGL in your profile.
Comment 18 Buovjaga 2020-08-28 12:01:40 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/