Hi, On Fri, Feb 5, 2016 at 2:02 AM, Chris Sherlock <chris.sherloc...@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ž _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
