Review Request 122673: Make Svg, FrameSvg work qith QT_DEVICE_PIXELRATIO

[Marco Martin]

> On Feb. 23, 2015, 10:17 a.m., David Edmundson wrote:
> > We don't want to alter the measures. Qt is already scaling co-ordinates by QT_DEVICE_PIXEL_RATIO. 
> > If we double them here we will surely end up scaling things twice?
> 
> Marco Martin wrote:
>     this is why devicepixelratio and scalefactor are now two different things.
>     devicepixelratio is current api and does scale measures. (so yeah, change in behavior that's bad, but whatever)
>     so the change makes such that devicepixelratio just scales the image and is usable with QT_DEVICE_PIXEL_RATIO.
>     scalefactor is pretty much the current method, that needs to still be supported for the time being, to both not break abruptly on existing systems and to wait qml primitive elements to be good enough themselves with it (is completely unsupported by native font rendering and Image at the moment)
> 
> David Edmundson wrote:
>     OK, I think I get it, after this patch:
>     
>     Svg::devicePixelRatio == the Qt way of scaling
>     Svg::scaleFactor == the Plasma way of scaling
>     Units::devicePixelRatio == the Plasma way of scaling, but floored to an integer.
>     
>     I don't understand this different thing with part integer and part floats; especially given Qt might be becoming a float.

Units::devicePixelRatio is still the plasma way of scaling, still float.
I tought about calling it scalefactor as well, but I know there are several places in qml code where this value is used to multiply sizes, so to remain more or less consistent would need to remain unaffected by QT_DEVICE_PIXEL_RATIO, so it doesn't get multiplied two times

svg scaling floored to integer in both cases(in its setters), since i tried to let it float and the result was quite ugly (still not completely gave up but scalings different from integer don't seem to look very good in general)


- Marco


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


On Feb. 22, 2015, 1:39 p.m., Marco Martin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122673/
> -----------------------------------------------------------
> 
> (Updated Feb. 22, 2015, 1:39 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> 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 
> 
> Diff: https://git.reviewboard.kde.org/r/122673/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150224/b6d4341d/attachment-0001.html>