CppunitTest_chart2_xshape Failure with Display Scaling on Windows

[Jan-Marek Glogowski]

Am 16. Dezember 2018 20:57:51 MEZ schrieb Luke Benes <lukebenes at hotmail.com>:
>The fix for Bug
>121685<https://bugs.documentfoundation.org/show_bug.cgi?id=121685>,
>https://cgit.freedesktop.org/libreoffice/core/commit/?id=7263d223ddf4
>​
>Is causing the core Unit Test CppunitTest_chart2_xshape to fail when
>you set,  Settings->Display->Scale=125%​

I had similar problems when I implemented https://cgit.freedesktop.org/libreoffice/core/commit?id=ada20402efa81273e03e46cbedc21f25b9daeeac

I'll just call this headless+, as this involves setting SAL_USE_VCLPLUGIN=svp and will only render output to bitmaps. The UI tests run this way without --headless, so they also get headless dialogs.

I found that various test failed, because DPI is an integer and our code results in various rounding errors sometimes adding up to large amounts. The headless / svp plugin already uses 96 DPI and now the headless+ mode in the osx plugin does the same. For similar reason IOS also explicitly sets 96 DPI.

The win plugin should also get a headless+ patch like the osx plugin, which just uses fixed 96 DPI. That's sufficient as a general test environment.

Actually it would also be nice to move the platform-independent stuff from Svp classes either into the Sal base classes or move platform stuff for IOS and Android into their own classes. My osx patch already duplicates code from headless, but I wanted that out without refactoring and breaking VCL again.
I had my share of unveiled bugs and breaking VCL this year. Maybe I'm more brave next year again ;-)

Jan-Marek

P.S. and maybe someone has some better / self-explaining name for the *BitmapRendering() functions. People complained but nobody proposed a better name yet.

P.P.S. implementing a SetHeadlessDPI-API might be a useable addition later. DPI already works per SalFrame, so a LO server should be able to render stuff for different DPIs. Actually that should already work, if you work with multiple screens with different DPIs, but at least in the osx backend the comments in the DPI detection code read as it is currently very broken.