> On July 21, 2014, 4:26 p.m., Marco Martin wrote: > > src/plasma/framesvg.cpp, line 480 > > <https://git.reviewboard.kde.org/r/119330/diff/5/?file=291470#file291470line480> > > > > are you sure about this one? > > doesn't contentGeometry returns the rectangle adjusted only by frame > > topHeight/RightHeight etc? > > > > the semantics of the function is supposed to return the rect adjust by > > visual margins for layout purposes (so the margin hints elements if present > > wins against the actual margin graphics, just like marginSize()). > > Aleix Pol Gonzalez wrote: > FrameSvgPrivate::contentGeometry takes them into account, because this > one does use the values in FrameData. > > Marco Martin wrote: > yeah, but I see from FrameData it's using frame->leftWidth, while in this > case it should use frame->leftMargin > (leftMargin being the same of leftWidth if there is no hint, the size of > the hint instead) > > Aleix Pol Gonzalez wrote: > Can you create a small test where I can reproduce the issue? > > Marco Martin wrote: > I think for at least measures should be possible to do an autotest.. I'll > give it a try
Here you go, in master there is an autotest that fails(QEXPECT_FAIL) comparing contentsRect - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62799 ----------------------------------------------------------- On July 21, 2014, 4:40 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, 4:40 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/framesvgitem.h e155f6a > src/declarativeimports/core/framesvgitem.cpp 8320212 > 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_helpers.h PRE-CREATION > src/plasma/private/framesvg_p.h 8aceef2 > tests/dialog.qml PRE-CREATION > tests/testborders.qml PRE-CREATION > > 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
