On 5 Feb 2016, at 6:37 AM, Norbert Thiebaud <nthieb...@gmail.com> wrote: > > On Thu, Feb 4, 2016 at 10:10 AM, Armin Le Grand <armin_le_gr...@me.com> wrote: >> >> Example: >> You have painted an ellipse (vector data). User chooses 'convert to Bitmap' >> and saves the file. On Mac you will have a >200 DPI bitmap, > > Just as a reminder. the 'DPI' on mac depend dynamically on the > 'Screen' on which you are drawing at that point in time. > you could have multiple screen, with different 'DPI', and they can > even change by system setting (although not supported by the > 'standard' system setting gui interface, it _is_ possible to configure > the OS so that a retina screen is used with 1 point = 1 pixel (rather > than the 1 point = 4 pixel you usually have on retina) (*) > > Ideally DPI 'awareness' you really not leak outside of vcl.. and even > in vcl be limited to place where we are in 'PhysicalCoordinate' > > Norbert > > (*) one of the issue is that our bitmap abstraction does not make the > distinction between point and pixel, which makes the page preview > thumbnails in impress for example, not able to get as crisp as they > could be on retina display.
There were a series of patches that handled hi-DPI displays in 2014 that Keith did for us and that were pushed by Kendy: > 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… 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. 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? 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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
