Am 06.10.2014 um 15:52 schrieb Richard Heck <***@lyx.org>:
> On 10/05/2014 03:29 PM, Stephan Witt wrote:
>> Am 02.10.2014 um 13:14 schrieb Stephan Witt <***@gmx.net>:
>>> Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:
>>>> Am 18.07.2014 um 10:26 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>>>>> Le 17/07/2014 23:24, Marcelo Galvão Póvoa a écrit :
>>>>>> I'm not sure how to easily get a pointer to the window containing the
>>>>>> current workarea in every part of the code I need to use pixel_ratio.
>>>>>> I could use the globally available qApp->activeWindow() macro, but
>>>>>> what if the active window is a dialog window instead of the workarea?
>>>>> This is why there is a method to set it on a QImage/QPixmap. One only needs to have the information when crating it.
>>>>>> Besides, I currently need the device_ratio in some parts outside the
>>>>>> Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
>>>>>> couldn't access the window from there.
>>>>> You could add a method to WorkArea that provides this information (GuiWorkArea knows that). Would RenderImage be able to use it?
>>>>>> Having multiple pixel ratios can indeed be an issue. For example, if a
>>>>>> GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
>>>>>> during initialization. But if the window is moved to a LowDPI screen
>>>>>> afterwards, the image ratio would need to be updated.
>>>>> Or a given LyX instance could have one window on one screen and another window on another screen.
>>>> Or you drag the LyX window from one screen with hi-res to another one with low-res.
>>>> E.g. from my laptop screen to the second screen on the TV.
>>>>> I suspect that "interesting" things will happen when a window with previews moves from on screen to another. Except if we already check the size of previews.
>>> I gave it a try to make some progress regarding the HiDPI stuff.
>>> First I've decided to split the task. I'd postpone the image scaling issues.
>>> Not only because of the dynamic nature of the preview rendering. It's a slightly
>>> more complex thing in general - we need to provide multiple image/icon sets for
>>> different pixel ratios, IMHO.
>>> My work is based on the first patch from Marcelo. I dropped the use of the global
>>> LyXRC member variable and made an alternate solution without it.
>>> See the attached patch. In principle it works. There is an issue with scrolling.
>>> The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
>>> it is drawn and the content of the region under at the left side of the main text
>>> area is a duplicate of the middle of the text area on the stop of the scroll operation.
>>> See the attached screen shot.
>>> <Bildschirmfoto 2014-10-02 um 13.04.08.png>
>> Now I have an improved patch without the scrolling issue. I'd like to commit it.
>> Are there any thoughts about it?
To answer myself:
The patch should introduce the pixelRatio() methods instead of pixel_ratio()
to follow the camelCase method naming rule. I'll adjust the patch accordingly.
> I assume this would (should?) also work for non-OSX HiDPI monitors? Do we know anything about this?
Yes, it should work were Qt supports this.
This is the list of files containing the string setDevicePixelRatio:
$ mdfind -onlyin qt-everywhere-opensource-src-5.3.2/qtbase setDevicePixelRatio
This is from the Qt5 documentation:
* qreal QWindow::devicePixelRatio() const
Returns the ratio between physical pixels and device-independent pixels for the window. This value is dependent on the screen the window is on, and may change when the window is moved.
Common values are 1.0 on normal displays and 2.0 on Apple "retina" displays.
I'd conclude it may work on iOS, Mac OS with Cocoa and perhaps on MS-Windows.
For Linux I cannot see any hint that it should work.