Re: CppunitTest_chart2_xshape Failure with Display Scaling on Windows

Am 16. Dezember 2018 20:57:51 MEZ schrieb Luke Benes <lukebenes@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.