> On July 21, 2014, 2:09 p.m., Marco Martin wrote:
> > It is possible to have neither private objects exported, neither public api 
> > added. Yes, it duplicates a bit of the implementation, but I rather prefer 
> > it a lot than either adding api or exporting private symbols.

It's possible to do it without duplicating code, therefore we should do that.


> On July 21, 2014, 2:09 p.m., Marco Martin wrote:
> > src/plasma/framesvg.h, line 290
> > <https://git.reviewboard.kde.org/r/119330/diff/4/?file=291452#file291452line290>
> >
> >     err, it's not really how I intended in the previous review.. adding 
> > public api is even worse...
> >     
> >     those 3 really don't give any extra information compared to what you 
> > can obtain with just the plain Svg api.
> 
> Aleix Pol Gonzalez wrote:
>     Well, then we'll have the exact same function in FrameSvgItem and 
> FrameSvg. I'm unsure this is any better.

If it's worse we can use the previous version of this patch.


- David


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


On July 21, 2014, 1:51 p.m., David Edmundson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119330/
> -----------------------------------------------------------
> 
> (Updated July 21, 2014, 1:51 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> -------
> 
> Use FrameSVG as 9 tiles instead of uploading a big texture of the finished 
> frame each time.
> 
> This also saves the cache being populated with full created frames in 
> different sizes; which end up taking up space in the disk and shared memory 
> cache as well as the GPU memory.
> 
> A code path falls back to the original uploading the entire texture if 
> obscure settings are used, i.e overlay.
> 
> Benchmarks:
>  - apitrace when resizing a frame goes from an average of 7.6ms per frame of 
> *CPU* time just for the swizzling and uploading to 1.4ms
>   
>  - GPU time also drops from 40us to 10us
> 
> Themes will need to remove stretch-borders (when we gain nothing from 
> stretching; i.e Breeze) to get the most out of it. 
> 
> 
> Diffs
> -----
> 
>   src/declarativeimports/core/svgitem.cpp 1ed0631 
>   src/declarativeimports/core/tooltipdialog.cpp e62ed6e 
>   src/plasma/framesvg.h dd6d8da 
>   src/plasma/framesvg.cpp fcc6809 
>   src/plasma/private/framesvg_p.h 8aceef2 
>   tests/dialog.qml PRE-CREATION 
>   tests/testborders.qml PRE-CREATION 
>   src/declarativeimports/core/framesvgitem.cpp 8320212 
>   src/declarativeimports/core/framesvgitem.h e155f6a 
> 
> Diff: https://git.reviewboard.kde.org/r/119330/diff/
> 
> 
> Testing
> -------
> 
> Tested oxygen + breeze + some random (and ugly) themes from kde-look.
> 
> Theme changes work.
> 
> Everything looks the same; including the borders on oxygen.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to