Am 06.10.2014 um 22:05 schrieb Marcelo Galvão Póvoa <marspeoples...@gmail.com>:
> On Sun, Oct 5, 2014 at 4:29 PM, Stephan Witt <st.w...@gmx.net> wrote: >> Am 02.10.2014 um 13:14 schrieb Stephan Witt <st.w...@gmx.net>: >> >>> Am 18.07.2014 um 10:39 schrieb Stephan Witt <st.w...@gmx.net>: >>> >>>> >>>> Am 18.07.2014 um 10:26 schrieb Jean-Marc Lasgouttes <lasgout...@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. >>>> >>>> Stephan >>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> JMarc >>> >>> 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. >>> >>> Stephan >>> >>> <0003-Add-basic-qt5-HiDPI-rendering-support.patch> >>> <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? >> >> Stephan >> > > I tested your patch a little and I found some of the quirks I've been > having when I worked with this: > > - Redrawing the cursor sometimes causes some drawing errors around > characters. If I hold left/right arrow key to move the cursor across > text, I get something like the attached screenshot. As I mentioned, my > patch avoids partial viewport updates to workaround this, but it is > not a decent solution. > > - Instant Preview of math formulas is not rendered in HiDPI. My patch > does this but has an ugly dependency on LyxRC. Yes, I know. I said I'll split the task into pieces. I'm working on an improved patch to get HiDPI preview already. Do you have a proposal how to get HiDPI icons? > - Dynamically changing window DPI (i.e, moving it between different > screens) makes the text blurry. I haven't tested this much, but maybe > it is related to some unflushed drawing cache? I've tested this too and didn't see it. But after that I changed the code. I'll investigate again. Thanks. Stephan
