Review Request 119406: Always take the painter based path for composeOverBorder

Aleix Pol Gonzalez aleixpol at kde.org
Tue Jul 22 14:26:47 UTC 2014


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


+1, this escentially means that it now will use the same code as it used in 5.0, so no regressions at least.

It means though, that everything that has composeOverBorders will be rendered by the CPU rather than the GPU.

- Aleix Pol Gonzalez


On July 22, 2014, 2:24 p.m., David Edmundson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119406/
> -----------------------------------------------------------
> 
> (Updated July 22, 2014, 2:24 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> -------
> 
> Always take the painter based path for composeOverBorder
> 
> We previously only supported compose-over-border when the centre was not
> set to tile.
> 
> A recent change to the breeze theme put everything into tiling, even if
> some things used compose-over-border, which broke opaque widgets.
> 
> Given that creating an opacityMask loads most of the image anyway, we
> can make use of the FrameSVG painter path and avoid any additional code
> complexity here.
> 
> 
> Diffs
> -----
> 
>   src/declarativeimports/core/framesvgitem.cpp a5fe315 
> 
> Diff: https://git.reviewboard.kde.org/r/119406/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140722/00833c6c/attachment.html>


More information about the Kde-frameworks-devel mailing list