Summary:
A FrameSvg can have wrong mask frame if image path has been changed after
the mask frame was generated. Take image path into account when deciding
whether the mask frame should be updated to address that problem.
Depends on D13384
Reviewers: #plasma, #frameworks, mart
Reviewed By: #plasma, mart
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D13496
Summary:
When trying to update the maskFrame, there is a chance that it is already
shared by several instances of FrameSvg. In that case, do not wreck maskFrame
and instead act as follows:
* deref it
* try to lookup a matching frame in the shared frames
* if there is the matching frame, use it
* otherwise create a new one
Reviewers: #plasma, #frameworks, mart
Reviewed By: #plasma, mart
Subscribers: mart, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D13384
Summary:
In some cases, when rendering frame svg background, measures & margins
do not correspond to `enabledBorders`. I.e. `bottomHeight` may be equal to 5,
but the bottom border is disabled. This causes visual artifacts like this
{F5878318, layout=center, size=full}
//Pay close attention to the bottom of the Task switcher. It has a transparent strip at the bottom, which shouldn't be there.//
The cause of this problem is that FrameSVGPrivate::alphaMask doesn't take enabledBorders
into account when it's making decision whether it should update maskFrame.
Just for reference, this is "after"
{F5878319, layout=center, size=full}
BUG: 382324
BUG: 390632
BUG: 391659
Test Plan:
* Triggered the Breeze task switcher (with compositing on and off)
* Didn't see any transparent strips
---
* Tried running FrameSvgTest, still passes
Reviewers: #plasma, #frameworks, mart
Reviewed By: #plasma, mart
Subscribers: abetts, mart, aseigo, broulik, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D13215
Summary:
FrameSVG documentation states
> ... topleft and topright will be ignored if top does not exist,
> and similarly for bottomleft and bottomright ...
Someone would assume that the same behaviour applies to the case
when left(or right) does not exist.
This change makes FrameSVG to comply with such expected behaviour.
### Before
{F5878439, layout=center, size=full}
The bottom border doesn't exist so the bottom-right corner should not
be drawn.
### After
{F5878440, layout=center, size=full}
Reviewers: #plasma, #frameworks, mart
Reviewed By: #plasma, mart
Subscribers: mart, kde-frameworks-devel
Tags: #frameworks, #plasma
Differential Revision: https://phabricator.kde.org/D13218
Summary:
There is no need to check whether `cachedBackground` is null, and if
it's null, return a null pixmap.
Reviewers: #plasma, #frameworks, apol
Reviewed By: apol
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D13287
Summary:
We were reporting that the margins were changing whenever anything changed
in a FrameSvg, this patch makes sure we are only reporting the changes
when it actually changes.
This also fixes a binding loop in Desktop.qml from plasma-desktop.
BUG: 382233
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: broulik, davidedmundson, plasma-devel, #frameworks
Tags: #plasma, #frameworks
Differential Revision: https://phabricator.kde.org/D8809
frame->fooHeight is the same as frame->fooFixedHeight if the border is enabled, we only meddle
with margins, not heights. Thus we can just do the lookup once and re-use the value.
Also store the hintFooMargin instead of doing the same exact lookup once for fixed
and once for non-fixed margins.
Differential Revision: https://phabricator.kde.org/D8135
Summary:
sometimes a frame changed enabled borders causing a dangling
pointer in s_sharedFrames, since oldkey was generated
with the new enabled borders, it generated a key not present
in the hash, tryed to remove it and left the one associated
with the old key in the hash.
if the need to reuse a frame with that key ever arised again,
we had a crash
BUG:378508
Test Plan:
couldn't reproduce the crash neither with or without patch,
with the patch, if i put debug in every place a framedata is removed,
searching if the key is in the hash before removing it, now
it's always true, before sometimes it was false
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: plasma-devel, #frameworks
Tags: #plasma, #frameworks
Differential Revision: https://phabricator.kde.org/D6162
requestedprefix requires to not have the "-", don't fail anymore in
q->hasElementPrefix(frame->requestedPrefix) in
FrameSvgPrivate::generateBackground
BUG:377893
Summary:
make sure the framedata creation/destruction is
completely in updateFrameData, makes easier to track
and possible to use the repaintsblocked logic.
now only one framedata instance should be created at startup.
CCBUG:376754
Test Plan:
* autotests pass, plasma runs ok, crash on 376754 not reproducible anymore
* possible to have a plasmashell session start without the creation of a single svg renderer (startups after the first when the cache is generated)
* on qml profiler, framesvgitem creation is ~12 msecs the first one created, ~2-300 musecs the subsequent ones, seems to be a bit better than before the whole refactor started
* tried against the latest patches that remove the binding loops, still correct rendering and no binding loop
* tried with both empty and existing cache in place
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, plasma-devel, #frameworks
Tags: #frameworks, #plasma
Differential Revision: https://phabricator.kde.org/D4707
Summary:
d8a1a9eb08 introduces an unintended code
change, resizeFrame() updates the margins and in turns calls
repaintNeeded. This isn't needed and is a binding loop if we ever have a
frameSVGItem whose size depends on it's own margins.
resizeFrame is different from setEnabledBorders / setElementPrefix /
theme changes because even though we need to create a new FrameData we
know any hints and margins won't change. FrameSvgItem::updateSizes
doesn't depend on the size in any way, so always gives the same result
as before. We still, however, need to call updateSizes to populate our
FrameData structure even if the results will be the same as the previous
FrameData.
This patch that introduces a flag to updateFrameData to determine if we
should emit that size hints may have changed or not.
Test Plan:
GDB showed where the loop was.
Read the old code, and looked for differences
Ran plasmashell, checked I had no binding loop, frames including button
which have
composeOverBorder which need the new FrameData all rendered correctly.
Reviewers: #plasma, #frameworks, mart
Subscribers: mart, broulik, plasma-devel
Tags: #plasma, #frameworks
Differential Revision: https://phabricator.kde.org/D4713
Summary:
give frameSvg the concept of repaintBlocked(), that enables and
disables the regeneration of the frame data when a property is set.
the use case is when often, a lot of properties are set one after
the other (such as prefix, enabled borders, size)
collapse the formely similar, but a bit different logic of frame
regeneration is a single function for better maintanability.
QML FrameSvgItem sets repaintblocked when it starts and releases it just on oncomponentCompleted
Test Plan:
plasmashell still starts, autotests still work, all frames are rendered correctly
the destruction of old frames is cutted by 50%. in the qml profiler
the creation time of a framesvgitem slightly improved, on this machine from around 26 msecs to around 21, can still be improved, but at least the code is a bit simpler
Reviewers: #plasma
Subscribers: davidedmundson, plasma-devel, #frameworks
Tags: #plasma, #frameworks
Differential Revision: https://phabricator.kde.org/D4414
Instead use iterators. Could be changed to using keyBegin or something like that potentially.
The destructor is called 400 times on plasmashell startup for me.
Before: 250,000ns
After: 110,000ns
Differential Revision: https://phabricator.kde.org/D4350
Plasma framework's FrameSVG class uses cached regions for efficiency. However
Coverity caught a mis-use of QCache in FrameSvg::mask(), which could lead to a
use-after-free situation. (CID 1291560)
Basically, any pointer passed into QCache::insert must be assumed to be deleted
after insert() has been called -- we can't then return that pointer to the
caller.
Moreover we were simply returning a pointer to calling code that had been (and
still would be) owned by QCache, which is unsafe as it can be deleted at any
time. The fix in both cases is to make a local copy of the QRegion from out of
the cache and return that.
REVIEW:126411
FIXED-IN:5.18
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)
Change-Id: I304aa0d80abf76abafac239be185dd3b2ab741b7
REVIEW:122673
Revert the changes in contentsRect, it was clearly not the best place to
put the code that contains the code that computes the content size.
Instead move the code in FrameSvgItem, duplicates data and code but works.
It's unreasonable to use private API, so make everything public API so that
every user of FrameSvg have as much features exposed as possible.
Reviewed by David Edmundson
While debugging a glitch I found out a bug in the painting code that hide
behind QRect documentation. See comment in sectionRect. This never rendered
correctly.
Given the FrameData and the total size, we get to know where is the
contents going to be and gives us the information to extrapolate where to
put all the borders and corners.
Reviewed by David Edmundson
Move variable declarations closer to its uses
Prefer using QSize than width and height separately, so we can pass it
around directly and use isEmpty
Remove duplicated code in the central piece drawing
Reduce type casts from QSizeF to QSize, we're always using it as a QSize,
so just make the cast once.
Remove redundant constructions like checking whether it's null and returning
null or unneeded arithmetics
Create a paintBorder function that can generically paint framesvg borders.
This helps us reduce duplicated code as well as improving the readability
of the code.
Reviewed by David Edmundson
since it is now possible to have different svg/framesvg with
different themes, s_sharedFrames must be indexed by theme first
what it's really the identifying thing is ThemePrivate, so it's indexed by that
this fixes a crash that occurs the second thime the theme gets changed
BUG:335472
