DPI and screen resolution on OS X

[Chris Sherlock]

> On 5 Feb 2016, at 9:29 PM, Tomaž Vajngerl <quikee at gmail.com> wrote:
> 
> Hi,
> 
> On Fri, Feb 5, 2016 at 2:02 AM, Chris Sherlock
> <chris.sherlock79 at 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.

Thank you :-)

>>> 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).

Sorry for asking silly questions, but I’m not entirely following. Why do we increase the scaling factor at 2*96, but then start scaling before we hit 192?

Just a little confused by this, I’m sure it’s something obvious I’m missing! :-)

> 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.

Cheers, I’ll put this on my list of things to do.

> 
>> 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?).

So it’s better to create a decorator class, I’ve actually wondered if this might be a better solution. Good info!

Thanks Tomaz, appreciate the response!

Chris