diff options
author | Armin Le Grand <Armin.Le.Grand@cib.de> | 2018-10-25 10:06:05 +0200 |
---|---|---|
committer | Armin Le Grand <Armin.Le.Grand@cib.de> | 2018-10-25 12:43:55 +0200 |
commit | 313392119522c21a6ecd14403d6f92c948149df7 (patch) | |
tree | fbd1a112a41f83d34c6bb6ea79eeccf73dba3e7b /drawinglayer/qa | |
parent | 8dec85a3b3f4cbd46b03f707458347a25cc22c15 (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.cxx | 13 |
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); } |