As it turns out, QString::number() is quite expensive, especially when
using it in a code path that is called a lot of times. So instead, use a
struct with a custom hash method as cache ID. This is significantly
faster since we do not need to do memory allocations or string
conversions.
This, I suspect, is the true source of bug 426674. FrameSvg would
request items from the cache without specifying any modification time
stamp, so we end up always retrieving the cached version. Since
lastModified is now a required parameter, we need to ensure this does
not happen anymore.
BUG: 426674
Summary:
Leverages QSharedPointer for the reference counting.
Keeps the last value of the cacheId, as it can change sometimes and crash
the system.
Reviewers: #plasma, #frameworks, zzag
Reviewed By: #plasma, zzag
Subscribers: mart, zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D17052
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:
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
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
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
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
All cpp code moves into the src/ subdirectory, as the Frameworks policy
suggests.
Directory structure should now be in line with other, future frameworks.
