On Thursday 21 of November 2019, Stephan Bergmann wrote: > On 21/11/2019 11:25, Chris Sherlock wrote: > > Just a quick query to the ML - when I’m attempting to troubleshoot > > issues with EMF files, I use SAL_INFO to see what records it is reading. > > It’s already helped me work out some issues, in particular the last one > > was around custom line caps. > > > > How else should we be doing this? > > I guess there's no ideal answer. While I agree that there's no ideal answer, the way I see it is that there should be a preferred answer, and that's how I see SAL_INFO. > > > Hm, sounds rather like a misuse of the SAL log facility to me. (Each > > > use of it comes at a cost, so it shouldn't be used too lightly for > > > anything but logging unusual events.) E.g. currently while writing the Skia VCL backend I've added SAL_INFO to pretty much to each of the drawing functions. And of course normally nobody wants to see that, but it can be useful if needed, all it takes is setting SAL_LOG, and it fits nicely with the code (no #ifdefs or anything). So I disagree with it being just for the unusual stuff (that's SAL_WARN). Is it really that costly? It's no-op for non-debug builds, and I was under the impression that even for debug builds it tries to be fast in the common case when it's a no-op. So I'd expect this to be insignificant, especially when compared to costs such as using debug mode libstdc++. -- Luboš Luňák l.lunak@xxxxxxxxxxxxx _______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice