Re: DPI and screen resolution on OS X

Hi,

On Fri, Feb 5, 2016 at 2:02 AM, Chris Sherlock
<chris.sherlock79@gmail.com> wrote:
> There were a series of patches that handled hi-DPI displays in 2014 that Keith did for us and 
> that were pushed by Kendy:

Yes, and I continued later on with the patches when I got a laptop
with HiDPI screen and running Fedora.

> > I've just pushed a backport of the hi-dpi patches from master to gerrit
> > for libreoffice-4-2 integration - as was requested earlier, to fix the
> > unfortunate state of LibreOffice on the hi-dpi displays.  It is the
> > following 5 patches (order is important):
> >
> > https://gerrit.libreoffice.org/#/c/8516/
> > https://gerrit.libreoffice.org/#/c/8517/
> > https://gerrit.libreoffice.org/#/c/8518/
> > https://gerrit.libreoffice.org/#/c/8519/
> > https://gerrit.libreoffice.org/#/c/8520/
> >
> > Keith confirmed that they fix the hi-dpi issues he was seeing in
> > LibreOffice 4.2.
> >
> > They are supposed to be safe for normal displays; that is anything
> > non-safe should be enclosed in an "if (mnDPIScaleFactor > 1)".  Few
> > cases make the computation a bit more general, like:
> >
> > +    long yOffset = (aRect.GetHeight() - mpImpl->maImage.GetSizePixel().Height()) / 2;
> > +
> >      if( mpImpl->mnState == SIGNATURESTATE_SIGNATURES_OK )
> >      {
> > -        ++aRect.Top();
> > +        aRect.Top() += yOffset;
>
> I’m wondering if this is the area I should focus on.
>
> I’m not entirely sure how the scaling factor is being worked out, we seem to do this in 
> Window::ImplInit and Window::ImplInitResolutionSettings with the following calculation:
>
> mnDPIScaleFactor = std::max(1, (mpWindowImpl->mpFrameData->mnDPIY + 48) / 96);
>
> Does anyone know what the underlying theory is behind this calculation? 96 seems to be a 
> hardcoded DPI value assumed for all screens, but I can’t quite work out where the 48 number comes 
> from…

You need the scale factor for bitmaps (icons) and some other places in
the UI (mostly the places where we draw 1 pixel lines) because when
you increase the DPI everything becomes larger pixel wise but bitmaps
stay as they are. When you start to approach 192 DPI (2*96) we
increase the scaling factor and scale the bitmaps by the scaling
factor. 48 is there only so that we scale before we hit 192 DPI - at
around 144 DPI (however in the latest code this starts at 169 DPI).

OSX is however excluded from this - it does its scaling in the backend
AFAIK. (see WIndow::CountDPIScaleFactor)

> I’m also wondering if it might not be better for us to move this calculation out of Window and 
> into SalGraphics, given it is the SalGraphics backend that really gives the DPI via GetResolution.

Yes, it would be better to do it in the backend I guess.

> Another thing is: we seem to have this idea of logical coordinates, as opposed to device 
> coordinates all through OutputDevice, and also there is a way of setting the OutputDevice 
> mapmode. I’ve never quite understood what the idea behind this is. Can anyone give me any 
> insights into this?

OutputDevice backends work only with pixels - you can set the mapmode
to a logical mode and all the inputs can be in that logical
coordinates. OutputDevice will automatically convert them to pixels. I
don't like this however. I think this doesn't belong on the
OutputDevice and it just adds bloat - if we need something like this
then as a wrapper around OutputDevice that does this
(LogicalOutputDevice?).

> Chris
>
> P.S. I’ve just checked my Mac and the default scaling option is indeed lower than what I was 
> expecting - the default on my Mac with a Retina screen is 2560x1440.
>
> Hint for OS X developers: to change actual screen resolutions, you need to:
>
> 1. Go to System Preferences
> 2. Go into the Display panel
> 3. In the Display tab, hold down the option key on your keyboard and click on the Scaled radio 
> option
>
> This will give you the chance to set the actual screen resolution, as opposed to the more limited 
> graphical option that OS X gives you.

Regards, Tomaž