This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122673/

On February 24th, 2015, 11:52 a.m. UTC, Kai Uwe Broulik wrote:

src/declarativeimports/core/framesvgitem.cpp (Diff revision 1)
void FrameSvgItem::componentComplete()
495	m_frameSvg->setDevicePixelRatio(qMax<qreal>(1.0, floor(m_units.devicePixelRatio())));	495	m_frameSvg->setDevicePixelRatio(qMax<qreal>(1.0, floor(qApp->devicePixelRatio())));

src/declarativeimports/core/framesvgitem.cpp (Diff revision 1)

void FrameSvgItem::componentComplete()

495

    m_frameSvg->setDevicePixelRatio(qMax<qreal>(1.0, floor(m_units.devicePixelRatio())));

495

    m_frameSvg->setDevicePixelRatio(qMax<qreal>(1.0, floor(qApp->devicePixelRatio())));

Doesn't QWindow have a devicePixelRatio()? That way we could, one day, have separate scaling per monitor.

On February 24th, 2015, 11:56 a.m. UTC, Marco Martin wrote:

yep, should eventually use that (tough i'm not sure yet) i should really find a way to have one units instance per screen (or qwindow) instead per qqmlengine, that's not going to be super easy compared how is done now

On February 24th, 2015, 4:28 p.m. UTC, Xuetian Weng wrote:

What would be the qApp->devicePixelRatio() value if QT_DEVICE_PIXEL_RATIO set to auto ? ...

On February 24th, 2015, 4:34 p.m. UTC, David Edmundson wrote:

it's automatically set to 1.0 or 2.0 depending on your screen

I realised now I didn't read your question properly.

It's the DPI of the highest screen. Rationale being if you supply a high DPI pixmap to a paintdevice with a devicePixelRatio of 1, then nothing bad will happen. It will just be implicitly scaled down.

- David

On February 22nd, 2015, 1:39 p.m. UTC, Marco Martin wrote:

Review request for Plasma.

By Marco Martin.

Updated Feb. 22, 2015, 1:39 p.m.

Repository: plasma-framework

Description

(still in progress but here for feedback) when QT_DEVICE_PIXELRATIO is something different from 1, the pixmaps generated by Svg will be scaled up to give a proper texture.

This is complementary but not replacing our current approach: the pixelratio that can be accessed by units is now in relation to the qt pixel ratio, spacings are also adjusted accordingly (therefore, spaces and sizes won't need an integer value like pixelratio)

svg introduces also a scaleFactor property (that is pretty much like its old pixelRatio) basically, scalefactor, will scale both the textures and all the reported sizes, (old method) pixelratio just scales textures without altering measures (like qt pixelratio likes) they are now both used and combined, so a) we can have this working before supporting officially qt pixelratio when will be good enough but b) keeping the old mwthod working for the time being c) by using both at the sae time we can at least scale sizes of values != from integers, for screens that are too dense for 1 and not enough for 2

Diffs

src/declarativeimports/core/framesvgitem.cpp (dae8a4f)
src/declarativeimports/core/svgitem.cpp (570c1c3)
src/declarativeimports/core/units.h (6c038ba)
src/declarativeimports/core/units.cpp (a740145)
src/plasma/private/svg_p.h (a31d0ac)
src/plasma/svg.h (0bcbd7a)
src/plasma/svg.cpp (0a0db5e)

View Diff