Hopefully not a result of fix for bug 129211, but when toolbars are detached and moved they leave trails over other toolbars and the sidebar deck. screen clip attached showing the Drawing object toolbar docked, then undocked and moved. The LO app frame shows the artifacts if it is moved. Document canvas will clear on zoom in/out. LO app frame will clear artifacts on maximize full size, and gone when back to frame size. On Windows 10 Home 64-bit (1903) with Intel HD Graphics 620 (26.20.100.7584) Version: 7.0.0.0.alpha0+ (x64) Build ID: 54b28638ab15f68731861ae903c732273b41f78a CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Created attachment 157643 [details] clip of LO with Skia rendering, moving toolbar leaving screen artifacts
Hmm, don't confirm on a Windows 10 Ent 64-bit (1903) with nVidia K2000 graphics (driver 26.21.14.4128) Version: 7.0.0.0.alpha0+ (x64) Build ID: 54b28638ab15f68731861ae903c732273b41f78a CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL Do not get the same visual artifacts. So this seems a driver issue and limited to Intel GPUs.
It seems we'll get same pbs as OpenGL, perhaps there'll be a similar blacklist file some time. Wait and see.
Does running with SAL_SKIA=raster set help (about dialog should say "UI render: Skia/Raster"?
(In reply to Luboš Luňák from comment #4) > Does running with SAL_SKIA=raster set help (about dialog should say "UI > render: Skia/Raster"? Yes, the residuals of moving the toolbars disappear when I issue 'set SAL_SKIA=raster' for a command line launch. Verrified variable is set with 'echo %SAL_SKIA%' returning "raster". For this GPU/driver pairing, clean rendering when Skia/raster rather than Skia/Vulkan is showing on about dialog. Guess we need to check both configurations for each issue?
Notice latest 100.7755 Intel driver build is now claiming support for Vulkan 1.2 API. This evening I will update problem HD Graphics 620 system to that driver and retest to see if things improve.
Installing latest Intel driver 100.7755 (with Vulkan 1.2 API support) does not resolve the rendering issue on this GPU. On a Lenovo ideaPad flex4. Name Intel(R) HD Graphics 620 PNP Device ID PCI\VEN_8086&DEV_5916&SUBSYS_39FD17AA&REV_02\3&11583659&1&10 Adapter Type Intel(R) HD Graphics Family, Intel Corporation compatible Adapter Description Intel(R) HD Graphics 620 Adapter RAM 1.00 GB (1,073,741,824 bytes) Installed Drivers C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_91e5ab5ed4687752\igdumdim64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_91e5ab5ed4687752\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_91e5ab5ed4687752\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_91e5ab5ed4687752\igd12umd64.dll Driver Version 26.20.100.7755
I've just pushed https://cgit.freedesktop.org/libreoffice/core/commit/?id=3081998ada2ad60d14f8b2343309fe79776f898a for detecting and blacklisting drivers. Can you please run with SAL_LOG=+INFO.vcl.skia and report the info it gives (it should be the first vcl.skia debug line)?
Ping.
Created attachment 158930 [details] still getting screen artifactes -- 2020-03-20 build Still getting artifacts with Skia/Vulkan on a Windows 10 (1909) with Intel HD Graphics 620 (drvr 26.20.100.7755) Vulkan/raster is unaffected. artifact extends from a hard break mid-frame, length extending past varies by position of toolbar. Version: 7.0.0.0.alpha0+ (x64) Build ID: 61d8d991a27c3bfe70e3b8d3b4ce4d8a41d18d2d CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
The undocked Sidebar deck is unaffected, just movements of undocked toolbars as docking "targets" get rendered.
(In reply to V Stuart Foote from comment #10) > > Vulkan/raster is unaffected. > That should have been "Skia/raster"...
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Luboš Luňák from comment #8) > Can you please run with SAL_LOG=+INFO.vcl.skia and report the info > it gives (it should be the first vcl.skia debug line)? ^^^ Either way, if raster works and Vulkan not, then it's very likely a driver bug. So either the drivers get blacklisted, or if you want, I can tell you how to try to enable some Skia Vulkan workarounds and you can try if you find the right one that would help.
(In reply to Luboš Luňák from comment #14) > (In reply to Luboš Luňák from comment #8) > > Can you please run with SAL_LOG=+INFO.vcl.skia and report the info > > it gives (it should be the first vcl.skia debug line)? > > ^^^ Unfortunately, I've never been able to get a useful log out of the non-debug TB Windows builds. > > Either way, if raster works and Vulkan not, then it's very likely a driver > bug. So either the drivers get blacklisted, or if you want, I can tell you > how to try to enable some Skia Vulkan workarounds and you can try if you > find the right one that would help. But I would need to set up a windows build system on the host with one of the affected Intel GPUs -- I may need some help when I get a system picked out.
@Luboš, for what it is worth, seems like the element leaving artifacts behind is not the frame boundry for the toolbar. Rather seems most of the leftovers, not being fully cleared, are from the outlined landing target appearing when the floating toolbar is being moved to dock.
Intel DCH driver update to 26.20.100.7985 version No change on an Intel HD Graphics 620 GPU leaving residuals for the toolbar docking location highlights... No issues with default GDI, or OpenGL rendering. Skia / raster is fine also. Just with Skia / Vulkan rendering. Version: 7.0.0.0.alpha0+ (x64) Build ID: d194171917978979ff90400133c2843ae7077db9 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
confirm problem in Версия: 7.0.0.0.alpha0+ (x64) ID сборки: f265b14d6f8e3e63260b3c8ecce48d4251288fea Потоков ЦП: 4; ОС: Windows 10.0 Build 18363; Отрисовка ИП: Skia/Vulkan; VCL: win; Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU Calc: threaded I have here DriverVersion: 26.20.100.7325 DriverDate: 10-7-2019 DeviceID: PCI\VEN_8086&DEV_591B&SUBSYS_1A101043&REV_04 AdapterVendorID: 0x8086 AdapterDeviceID: 0x591b AdapterSubsysID: 0x1a101043 DeviceKey: System\CurrentControlSet\Control\Video\{EAD2925E-7135-11EA-9DAF-BD7266DE710B}\0000 DeviceString: Intel(R) HD Graphics 630
Created attachment 159193 [details] Problem with Skia/Vulcan
(In reply to Roman Kuznetsov from comment #19) > I have here > > DriverVersion: 26.20.100.7325 > DriverDate: 10-7-2019 > DeviceID: PCI\VEN_8086&DEV_591B&SUBSYS_1A101043&REV_04 > AdapterVendorID: 0x8086 > AdapterDeviceID: 0x591b > AdapterSubsysID: 0x1a101043 > DeviceKey: > System\CurrentControlSet\Control\Video\{EAD2925E-7135-11EA-9DAF- > BD7266DE710B}\0000 > DeviceString: Intel(R) HD Graphics 630 Roman, that is kind of an old driver, and if you'd like to update the ICH driver for your Intel GPU they are here: https://downloadcenter.intel.com/download/29465/Intel-Graphics-Windows-10-DCH-Drivers?product=80939
(In reply to Roman Kuznetsov from comment #19) > DriverVersion: 26.20.100.7325 This is the marketing version of the drivers. Blacklisting needs the internal driver version as reported by Vulkan, which is most likely different. See comment #8 on how to get it from LO. If you do not have a debug build, then possibly the number is visible in some control panel of the drivers (that's the case at least with AMD drivers).
The os 'dxdiag.exe' and 'msinfo32.exe', even the TechPowerUP GPU-Z [1] offer no details on Vulkan internals. But, the realtech-VR OpenGL Viewer utility (currently ver. 6.09) provides pretty complete coverage of Vulkan http://www.realtech-vr.com/home/glview For my Intel HD Graphics 620 w/Driver Version 26.20.100.7985 OpenGL Viewer report (need to submit to build a directory of XML reports for each OpenGL and Vulkan feature levels). <VKView version="6.0.5"><System>Windows 10 x64 Home Edition (Build 9200)</System> <deviceName>Intel(R) HD Graphics 620</deviceName> <apiVersion>1.2.131</apiVersion> <deviceID>5916</deviceID> <vendorID>8086</vendorID> <driverVersion>0.401.3889</driverVersion> @Luboš, is that '0.401.3889' what you'd expect/need internally to work against? =-ref-= [1] https://www.techpowerup.com/download/techpowerup-gpu-z/
> > @Luboš, is that '0.401.3889' what you'd expect/need internally to work > against? And, I get this Vulkan report from realtech-VR OpenGL Extension Viewer on my Windows 10 Enterprise workstation: <VKView version="6.0.5"><System>Windows 10 x64 Edition (Build 9200)</System> <deviceName>Quadro K2000</deviceName> <apiVersion>1.1.119</apiVersion> <deviceID>ffe</deviceID> <vendorID>10de</vendorID> <driverVersion>441.112.0</driverVersion>
It could be one of those version numbers, but the best will be if you try it yourself. In your LO installation directory find share/skia/skia_blacklist_vulkan.xml , it contains a commented out example. If you uncomment it, change the "amd" to "intel" and set the version, then you can try if you can still launch LO with Vulkan enabled. If LO will insist on using raster with Skia, then that's the right version number for blacklisting.
(In reply to Luboš Luňák from comment #25) > It could be one of those version numbers, but the best will be if you try it Did so. Seems useful! For Intel HD Graphics 620 with the Intel 26.20.100.7985 ver driver, the OpenGL Viewer reported Vulkan driver 0.401.3889 is correct. The device ID did need to be prepended with 0x for the blacklisting to process (not sure if that is OpenGL Viewer trim, or our blacklist parsing). Anyhow, tested the various permutations of values--this is the final *specific* to this GPU and driver set. <entry os="10" vendor="intel" compare="equal" version="0.401.3889"> <device id="0x5916"/> </entry> And, verified rendering mode follows the 'Ignore Skia blacklist' checkbox from Tools -> Options -> View set & relaunch. Will check similar on the nVidia K2000 workstation in a bit.
Here is another set of STR Not just toolbars, but the Sidebar deck is affected. With Skia / Vulkan rendering, dragging the Sidebar deck (any content panel) wider or narrower will leave artifacts--looks like reposition of the left edge of the deck. Interesting that if dock is dragged and docked to left edge, the artifacts do not appear. Likewise when docking a floating toolbar, working on the left side of the panel--no artifacts for the drop target. It seems like the left behind artifacts (toolbar or sidebar deck) only occur on the right ~1/4 of the display (1920 x 1080)--so a buffering/register issue for the Intel GPUs affected (HD Graphics 920, 930 w 1GB VRAM). Testing Version: 7.0.0.0.alpha0+ (x64) Build ID: f0bf741e0cda449666a9648f5bd2cef7c4d919d0 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
So for Intel 630 I got: Driver version: 0.401.3229 Vendor ID: 8086h Device ID: 591bh
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ecf58d6e961d88a7e951988c3c3fbcdc24860bab workaround for intel Skia invert() problem (tdf#130430) It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed. Toolbars, Sidebar decks no longer leaving artifacts during move on right 1/4 of 1920x1080 HD display panel with Skia / Vulkan rendering, no issues with Raster mode. Version: 7.0.0.0.alpha0+ (x64)Build ID: 96f77910e86f88c99621a8b17c09fc69f9f1d8f3CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win; Locale: en-US (en_US); UI-Language: en-USCalc: threaded RenderMethod: vulkan Vendor: 0x8086 Device: 0x5916 API: 1.2.131 Driver: 0.401.3889 DeviceType: integrated DeviceName: Intel(R) HD Graphics 620 Blacklisted: no @Luboš, would there be a way to check from time to time if future Intel drivers would correct the issue and allow you to remove the work around?
(In reply to V Stuart Foote from comment #30) > @Luboš, would there be a way to check from time to time if future Intel > drivers would correct the issue and allow you to remove the work around? That checking would presumably need to be done by you. And I think by now it might be possible to disable the workaround. Do you have LO built from source, so that you could try a change?
(In reply to Luboš Luňák from comment #31) > (In reply to V Stuart Foote from comment #30) > > @Luboš, would there be a way to check from time to time if future Intel > > drivers would correct the issue and allow you to remove the work around? > > That checking would presumably need to be done by you. And I think by now it > might be possible to disable the workaround. Do you have LO built from > source, so that you could try a change? Crud, I've donated the problem laptop with Intel HD Graphics 620, no longer have access to it. I'll see if I can scrounge a laptop with either an Intel HD Graphics 620 (deviceID: 0x5916 ) or HD Graphics 630 (deviceID: 0x591b ) and try to set it up for a Windows build machine. Probably will need your help then as to which pieces to comment out.
I found somebody else with Intel card who could test this for me and it appears this isn't a problem anymore (I remember I could reproduce it before too when I had access to an Intel machine). I've pushed a different way of handling this with https://git.libreoffice.org/core/+/110fa313628c55fef1d35830358aea7e27c1e3ee%5E%21 so I'll assume this will work fine now, unless proven otherwise.