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
Details
Details
- Reviewers
davidedmundson - Group Reviewers
Plasma - Commits
- R242:2b3e8dfe866a: move setImagePath logic into updateFrameData()
- 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
Diff Detail
Diff Detail
- Repository
- R242 Plasma Framework (Library)
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
| src/plasma/framesvg.cpp | ||
|---|---|---|
| 808 | I don't understand this and the FrameData part of this change. q->imagePath() will still always be correct as before, you still set that in setImagePath() regardless of whether we are blocking updates or not. | |
| src/plasma/framesvg.cpp | ||
|---|---|---|
| 808 | i need this because one check, in updateFrameData() can have the following situation: imagepath was updated during repaintBlocked, so q->imagePAth() becomes different from frameData->imagePath from line 670 we temporarly assign the new values to framedata, so we can compare the two keys (we don't know which among enabledBorders, frameSize and imagePath changed, if any) so i need to generate a cacheid with imagePath eventually in some cases different from q->imagePath() | |