Am 08.10.2014 um 12:19 schrieb Stephan Witt <st.w...@gmx.net>: > Am 07.10.2014 um 15:58 schrieb Jürgen Spitzmüller <sp...@lyx.org>: > >> 2014-10-07 15:44 GMT+02:00 Jean-Marc Lasgouttes: >> Le 07/10/2014 13:10, Jürgen Spitzmüller a écrit : >> In that case, we could probably set up a script that generates those @2x >> icons (as well as icons of diverse size) from the SVG. This could also >> be used in order to generate bigger icons for other purposes (think >> tablet UI). >> >> Why not use directly the svg versions? Is it bad in terms of performance? >> >> If this is possible with the Qt HDPI approach (i.e., if it does not requires >> those @2x icon bitmap files). I have not checked that, but if I understand >> this correctly, it should be possible: >> http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/ >> >> Quote: >> >> "As we have seen, raster content won’t look nice when scaled and >> high-resolution content should be provided. As an app developer you have two >> options: (ignoring the “do-nothing” option) >> • Replace existing raster content with a high-resolution version >> • Provide separate high-resolution content >> The first option is convenient since there is only one version of each >> resource. However, you may find (or your designer will tell you) that >> resources like icons look best when created for a specific resolution. To >> facilitate this, Qt as adopted the “@2x” convention for image filenames:" >> >> SVG would be "first option", no? > > Yes, I think so. > > The nice effect of using the “@2x” convention is the assignment of the correct > devicePixelRation to the images Qt creates that way. > > Stephan
Now I have an updated patch including hi-dpi preview and icons. It is really obfuscated now. I don't want to commit it as this monster patch. I'll try to explain it for review therefore… * Buffer::fontScalingFactor() demonstrates we have a problem with other LyXRC variables already with preview snippets. Change of the zoom doesn't scale the preview snippets accordingly. And I'm not sure the value of dpi is constant, too. * The BufferParams.display_pixel_ratio member will be set to the magnification the app wants. This happens when the buffer is assigned to the work area. Not as clean as I want but I couldn't come up with a better solution. * The file lookup is extended with a mode to search for hi-dpi versions of an image file. In case we go the "SVG"-route this of course has to be changed. But I don't know how, ATM. * GuiPainter::image method had used complete wrong parameters for Qt drawImage() call, IMHO. It used to work because of source rect being of the same size as destination rect. * The width and height of a GuiImage returns device independent "logical" values. I'm not sure if this is the best solution. But it works now. If this changes one has to adapt all callers of GuiImage::width or GuiImage::height. BTW: Does anyone know how to find all callers of a C++ method? I'm used to have this at hand when working with Eclipse and Java. I cannot find this feature neither in Eclipse for C++ nor in XCode. Is there any IDE with this functionality? Refactoring of code would be much more easy with this :( Stephan
0007-Add-basic-qt5-HiDPI-rendering-support.patch
Description: Binary data
