summaryrefslogtreecommitdiff
path: root/drawinglayer/qa
diff options
context:
space:
mode:
authorArmin Le Grand <Armin.Le.Grand@cib.de>2018-10-25 10:06:05 +0200
committerArmin Le Grand <Armin.Le.Grand@cib.de>2018-10-25 12:43:55 +0200
commit313392119522c21a6ecd14403d6f92c948149df7 (patch)
treefbd1a112a41f83d34c6bb6ea79eeccf73dba3e7b /drawinglayer/qa
parent8dec85a3b3f4cbd46b03f707458347a25cc22c15 (diff)
Reorganize FrameBorderPrimitive creation (II)
Step5: Move the view-dependent decomposition from BorderLinePrimitive2D to SdrFrameBorderPrimitive2D. It is now possible to use discrete sizes before the line and edge matching is done what will look much better. When it was done at BorderLinePrimitive2D and the matching was already done, that match was 'displaced' with the adapted forced scale to discrete units. The space and size used when zooming out for a single discrete unit (pixel) can heavily vary - it just covers a much larger logical area than the 'real' line/poly would do. All this needs to be handled (also for bound ranges) and can only be in a good way using primitives. Adapted to no longer do view-dependent changes in BorderLinePrimitive2D. Adapted to do these now at SdrFrameBorderPrimitive2D. Currently used to force the existing border partial lines (up to three) to not get taller than one logical unit. Adapted to no longer switch off AntiAliased rendering in VclPixelProcessor2D for processBorderLinePrimitive2D, this is problematic with various renderers on various systems (e.g. vcl still falls back to render multiple one-pixel-lines when taller than 3.5 pixels which looks horrible combined with other parts like filled polygons) All this needs fine balancing on - all systems - all renderers - all apps (which all have their own table implementation) - all render targets (pixel/PDF/print/slideshow/...) Done as thorough as possible, but may need additional finetuning. May also be a motivation to move away from vcl and implement these urgetly needed system-dependent primitive renderers... Adapted UnitTest testDoublePixelProcessing with the needed comments. Change-Id: Ie88bb76c2474b6ab3764d45a9cd1669264492acd Reviewed-on: https://gerrit.libreoffice.org/62344 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
Diffstat (limited to 'drawinglayer/qa')
-rw-r--r--drawinglayer/qa/unit/border.cxx13
1 files changed, 11 insertions, 2 deletions
diff --git a/drawinglayer/qa/unit/border.cxx b/drawinglayer/qa/unit/border.cxx
index 365c90d1691f..30d278a91560 100644
--- a/drawinglayer/qa/unit/border.cxx
+++ b/drawinglayer/qa/unit/border.cxx
@@ -189,7 +189,7 @@ void DrawinglayerBorderTest::testDoublePixelProcessing()
{
auto pMPLAction = static_cast<MetaPolyLineAction*>(pAction);
- if (0 == pMPLAction->GetLineInfo().GetWidth() && LineStyle::Solid == pMPLAction->GetLineInfo().GetStyle())
+ if (0 != pMPLAction->GetLineInfo().GetWidth() && LineStyle::Solid == pMPLAction->GetLineInfo().GetStyle())
{
nPolyLineActionCount++;
}
@@ -198,7 +198,16 @@ void DrawinglayerBorderTest::testDoublePixelProcessing()
// Check if all eight (2x four) simple lines with width == 0 and
// solid were created
- const sal_uInt32 nExpectedNumPolyLineActions = 8;
+ //
+ // This has changed: Now, just the needed 'real' lines get created
+ // which have a width of 1. This are two lines. The former multiple
+ // lines were a combination of view-dependent force to a single-pixel
+ // line width (0 == lineWidth -> hairline) and vcl rendering this
+ // using a (insane) combination of single non-AAed lines. All the
+ // system-dependent part of the BorderLine stuff is now done in
+ // SdrFrameBorderPrimitive2D and svx.
+ // Adapted this test - still useful, breaking it may be a hint :-)
+ const sal_uInt32 nExpectedNumPolyLineActions = 2;
CPPUNIT_ASSERT_EQUAL(nExpectedNumPolyLineActions, nPolyLineActionCount);
}