Don't know it would really be helpful to do this only for Skia related issues.

Currently for QA we refer folks to Wiki

https://wiki.documentfoundation.org/UserProfile#Default_locations

https://wiki.documentfoundation.org/UserProfile#Resolving_corruption

and in

https://wiki.documentfoundation.org/QA/FirstSteps

we cover the Skia.log as recorded to the <User profile>/cache.

Don't know that needs to be baked into the UI, at most some generic for help article for where the logging/config details are?

Perhaps it might help but don't know how to add something on UI so can't help here, uncc myself.

Just some code pointers:
vcl/skia/SkiaHelper.cxx:126:    SvFileStream logFile(getCacheFolder() + "/skia.log", StreamMode::WRITE | StreamMode::TRUNC);
vcl/skia/SkiaHelper.cxx:151:    SvFileStream logFile(getCacheFolder() + "/skia.log", StreamMode::WRITE | StreamMode::TRUNC);
vcl/skia/SkiaHelper.cxx:158:    SvFileStream logFile(getCacheFolder() + "/skia.log", StreamMode::WRITE | StreamMode::TRUNC);

QA people and developers shouldn't struggle to find the user profile and read the log file. And ordinary users should not face crashes anyway. So -1 to make it easier to access.

(In reply to Heiko Tietze from comment #3)
> QA people and developers shouldn't struggle to find the user profile and
> read the log file. And ordinary users should not face crashes anyway. So -1
> to make it easier to access.

The whole point being that we have to ask ordinary users for feedback. Unsure if we can call bug reporters at bugzilla 'ordinary users', though. 

The Skia Vulkan crashes are - so it seems - highly dependent on driver + graphic chipset. QA has only limited access. Even developers unable to reproduce those crashes, which makes them pretty much unsolvable.

Also keep in mind: the causes are in multiple layers. Driver issue, Skia backend-issue, implementation issue at LibreOffice. And obviously mostly some combination of all three.

--
Ordinary users should not face crashes anyway. 

Fully agree. 

My personal preference would be to make Skia Vulkan opt-in. So default being Skia Raster. Performance is decent. Not as fast as Vulkan, but not prone to crashes either as far I'm aware.

Arguments:
* There is no developer activity at the Skia front for a while. 
* The Skia Vulkan has known crashing issues - like Bug 149527 and bug 153922
* See the crash reporter stats. dll's major crashes point to dll's of graphic cards. Likely crashing once, and activating fall-back to Skia-Raster (https://crashreport.libreoffice.org/stats/) igc64.dll / igvk64.dll
* The sudden crashes are causing dataloss left and right; maybe indirectly exposing some issue with document system. 
* People who need the extra performance can still opt for Vulkan, but usage is at their own risk. 
* It makes the access to the skia.log less problematic. Less users will rely on Skia Vulkan, less crashes...

We could perhaps add the text to the log produced by the Run Graphics Tests tool? That way, people have an install-agnostic way to get it within the UI, while adding nothing new to the UI.

If the log is not too long we could copy it with the version button in the about box.

Bug 155084 is proto-typical example why would like some quick way to access the skia.log

I currently tend to point to Menu -> Tools -> Options -> View -> Check 'Force Skia Software Rendering' if I expect it to be Skia Vulkan related. See bug 155084 comment 3.

However if I do that, and it solved the problem, people don't tend to turn skia Vulkan back on again the retrieve the skia.log. Which needed for blacklisting drivers.

It's rather clumsy to ask people for the dig out the skia.log in advance (which is little time consuming). Turning on Skia Software Rendering and next concluding, well it wasn't skia at all..


--
Adding it to Help About is something to consider. I doubted it a bit because it adds some excess in quite number of cases (it's trivial in >85% of the cases). OTOH, the 'ordinary users' will report more relevant information Skia Vulkan cases with the initial report. So it would make stuff easier for Skia Vulkan issues :-)

Alternatively to About: Version I could imagine a tiny hyperlink "Copy Log file" next to Tools > Options > View > Skia, ideally disabled if there is no log file to copy. Could be accomplished with a tooltip "Copy the content from skia.log to the clipboard", and on click it does this.

(In reply to Heiko Tietze from comment #8)
> Alternatively to About: Version I could imagine a tiny hyperlink "Copy Log
> file" next to Tools > Options > View > Skia, ideally disabled if there is no
> log file to copy. Could be accomplished with a tooltip "Copy the content
> from skia.log to the clipboard", and on click it does this.

Also fine..

Yes, I agree with an easier "copy skia.log" in:

- About > Help

or:

- Tools > Options > View

- - -

This would help debug in cases like:

- https://www.reddit.com/r/libreoffice/comments/12x9glm/does_anyone_else_have_a_giant_gpu_memory_leak/jhqjin2/
- https://www.reddit.com/r/libreoffice/comments/10p6o5a/this_is_an_ancient_lo_writer_bug_still_present_in/j6yhhlc/
- https://www.reddit.com/r/libreoffice/comments/sjujvd/libre_office_writer_crashing_within_10_seconds_of/hvj8aw5/

And it would be easier to give simple instructions for all OSes, instead of something like:

> If on Windows, go to:
>
> - C:\Users\[YOURUSERNAMEHERE]\AppData\Roaming\LibreOffice\4\cache
>
> If on Mac, go to... If on Linux, go to...

- - -

> And ordinary users should not face crashes anyway.

lol. But they do!

- - -

Side Note: And, a big portion of these "disable skia" problems seem to be laptops with integrated+dedicated GPUs, so various mixes of older Intel/NVIDIA/AMD drivers at play.

Many "normal users" may just follow whatever Windows installs, not necessarily staying up-to-date with the latest straight from NVIDIA/AMD.

So, whatever we can do to make gathering this info easier from users facing crashes would be a plus in my book. :)

- - -

Side Note #2: A whole other class of users constantly say "disable skia" as the 1st step. There's YEARS AND YEARS of this "advice" in topics/posts like:

- https://www.reddit.com/r/libreoffice/comments/kqp69v/libreoffice_7_ui_lag_on_windows_10_laptop_resolved/

If it solved the original user's problem, they never come back to give more detailed info, so we never figure out WHY LO "lagged" / "ran slow" / "crashed" or "didn't run properly" in the first place...

Again, a simpler skia.log button may help capture some of that as well.

If their problem gets solved, it may be easier to get them to:

- Press a button + paste skia info

vs.:

- having them dig through buried folders/files.

(In reply to Heiko Tietze from comment #8)
> Alternatively to About: Version I could imagine a tiny hyperlink "Copy Log
> file" next to Tools > Options > View > Skia, ideally disabled if there is no
> log file to copy. Could be accomplished with a tooltip "Copy the content
> from skia.log to the clipboard", and on click it does this.

Happy with extra, discrete UI to "copy Skia log to clipboard", either in the Options dialog (it would be more useful than the Run Graphics Tests button, see bug 155069), or in the About dialog.
(As long as it's not copied along with the Help > About version information, which is already bulky enough as it is and would make for unnecessarily busy comments in Bugzilla).

Setting to New based on Tex, Telesto and Heiko's comments.

Hossein, could it be a topicQA easyHack ?

(In reply to Stéphane Guillou (stragu) from comment #11)
> (As long as it's not copied along with the Help > About version information,
> which is already bulky enough as it is and would make for unnecessarily busy
> comments in Bugzilla).

Yes, full agree there. No need to include it every time.

Only in an easy-to-access spot QA/others can ask for in very specific cases. :)

Here we go https://gerrit.libreoffice.org/c/core/+/151699

Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4356790bdf493c68ab609468603ec57e98dd2dae

Resolves tdf#155070 - Easy access to skia.log

It will be available in 7.6.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.

Maybe it's irrelevant, but I wonder if the "Requires restart" tooltip can be suppressed in case of the button.

(In reply to Buovjaga from comment #16)
> Maybe it's irrelevant, but I wonder if the "Requires restart" tooltip can be
> suppressed in case of the button.

Have seen it but forgot to look into. Patch at https://gerrit.libreoffice.org/c/core/+/151764

Some ideas:

1. Before clicking on the copy button, the copy icon does not appear. Is this the intended behavior?

2. On X11/Skia on Linux, this is the only thing I get:

RenderMethod: raster
Compiler: Clang

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: d2756dbd9b11bdfbf1d576381b8f9846a6fb7070
CPU threads: 12; OS: Linux 5.19; UI render: Skia/Raster; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: CL threaded

3. On Windows, I tried to copy, and then paste inside LibreOffice Writer. I got this error message in a popup: "Information: Requested clipboard format is not available". I also could not paste into notepad. This is when Skia is disabled by unchecking the appropriate check box above the new button.

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: d2756dbd9b11bdfbf1d576381b8f9846a6fb7070
CPU threads: 32; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded

When Skia is enabled, I get:

RenderMethod: raster
Compiler: Clang

(In reply to Hossein from comment #18)
> 1. Before clicking on the copy button, the copy icon does not appear. Is
> this the intended behavior?
The icon is the feedback for the action.

> 2. On X11/Skia on Linux, this is the only thing I get:
> 
> RenderMethod: raster
> Compiler: Clang
And with kf5/gen the button and all other controls are disabled.

> 3. On Windows, I tried to copy, and then paste inside LibreOffice Writer. I
> got this error message in a popup: "Information: Requested clipboard format
> is not available".
> ...
> When Skia is enabled, I get:
> RenderMethod: raster
> Compiler: Clang

Could disable the button depending on Skia. But why would you click in the first place? Rhetorical question, users just click.

(In reply to Heiko Tietze from comment #19)

> 
> Could disable the button depending on Skia. But why would you click in the
> first place? Rhetorical question, users just click.

Obtaining the log is to assist trouble shooting Skia/Vulkan vector graphics acceleration.  When Skia/Vulkan fails (or is reset from Options --> View) on LO relaunch the log will be emptied to the fall-back Skia/software only rendering log holding "RenderMethod: raster" and compiler strings.

That detail is useless.

To obtain the Skia Vulkan log--the user has to set Skia/Vulkan active and restart LO.

So, offering the control when Skia / Vulkan is not enabled  active is not very helpful.  The string is recorded to the Help -> About, so we already capture the status.  Supress the button/action when not in Vulkan rendering mode.

Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/90a8073fa5a6a724de498130476895dfaf4429b5

Related tdf#155070 - Tooltips moved from container to controls

It will be available in 7.6.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.

Tooltips are now assigned to the checkboxes only and the log button is disabled depending on Skia on/off.

(In reply to Heiko Tietze from comment #22)
> Tooltips are now assigned to the checkboxes only and the log button is
> disabled depending on Skia on/off.
Thank you Heiko! It is much better now.

Also, now that I've unchecked "Force Skia software rendering", I see more information:

RenderMethod: vulkan
Vendor: ...
Device: ...
API: ...
Driver: ...
DeviceType: integrated
DeviceName: Intel(R) Graphics (...)
Denylisted: no

So, in case of software rendering, I would expect that I am told that it is using software rendering. The same information in case of hardware rendering would be useful. Probably deserve a new ticket. :-)

(In reply to Hossein from comment #23)
> So, in case of software rendering, I would expect that I am told that it is
> using software rendering. The same information in case of hardware rendering
> would be useful. Probably deserve a new ticket. :-)

Yes, my patch just copies the log file for easier access. The log details should be done by a real developer.

Verified fix in the latest LO 7.6 dev master:

Active "Copy skia.log" button:

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: c01639c556276e496d9e762468cad6b27f9ed0f4
CPU threads: 12; OS: Linux 5.19; UI render: Skia/Vulkan; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: CL threaded

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: ef656fbc75187eb0fc4a750bb9afea839b8215ed
CPU threads: 32; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded

Disabled "Copy skia.log" button:

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: c01639c556276e496d9e762468cad6b27f9ed0f4
CPU threads: 12; OS: Linux 5.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: CL threaded