office-gobmx/drawinglayer
Stephan Bergmann b512ce255f Make upcasting css::uno::Reference ctor require complete types
The main reason for the "home-grown" UpCast introduced with
904b3d1fce "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then.  A (welcome) side effect was that the derived class
could be incomplete.

However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others.  And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.

That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fe "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met.  This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").

Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-27 07:19:30 +02:00
..
inc update pches 2020-04-26 15:34:06 +02:00
qa/unit
source Make upcasting css::uno::Reference ctor require complete types 2020-04-27 07:19:30 +02:00
CppunitTest_drawinglayer_border.mk
drawinglayer.component
IwyuFilter_drawinglayer.yaml
Library_drawinglayer.mk split up polypolygonprimitive2d.cxx into separate files 2020-04-07 01:47:30 +02:00
Makefile
Module_drawinglayer.mk
README

Drawing API that can specify what to draw via a kind of display list.

Example of the DrawingLayer use is eg. in svx/source/xoutdev/xtabhtch.cxx:121.
A stripped down version with extended comments:

     // Create a hatch primitive (here a rectangle that will be filled with
     // the appropriate hatching, but has no border).
     // This will not draw it yet; it's so far only constructed to add it to a
     // display list later.
     const drawinglayer::primitive2d::Primitive2DReference aHatchPrimitive(
         new drawinglayer::primitive2d::PolyPolygonHatchPrimitive2D(...));

     // Create a rectangle around the hatch, to give it a border.
     const drawinglayer::primitive2d::Primitive2DReference aBlackRectanglePrimitive(
         new drawinglayer::primitive2d::PolygonHairlinePrimitive2D(...));

     // Here we want to render to a virtual device (to later obtain the bitmap
     // out of that), so prepare it.
     VirtualDevice aVirtualDevice;

     // Create processor and draw primitives, to get it ready for rendering.
     std::unique_ptr<drawinglayer::processor2d::BaseProcessor2D> pProcessor2D(
         drawinglayer::processor2d::createPixelProcessor2DFromOutputDevice(...));

     if (pProcessor2D)
     {
         // Fill-in the display list.
         drawinglayer::primitive2d::Primitive2DSequence aSequence(2);

         aSequence[0] = aHatchPrimitive;
         aSequence[1] = aBlackRectanglePrimitive;

         // Render it to the virtual device.
         pProcessor2D->process(aSequence);
         pProcessor2D.reset();
     }

     // Obtain the bitmap that was rendered from the virtual device, to re-use
     // it in the widget.
     aRetval = aVirtualDevice.GetBitmap(Point(0, 0), aVirtualDevice.GetOutputSizePixel());

== DrawingLayer glossary ==

Primitives - classes that represent what should be drawn.  It holds the data
what to draw, but does not contain any kind of the rendering.  Some of the
primitives are 'Basic primitives', that are primitives that cannot be
decomposed.  The rest of the primitives can be decomposed to the basic
primitives.

Decomposition - a way how to break down the more complicated primitives into
the basic primitives, and represent them via them; this logically makes the
plain Primitive2DSequence display list a hierarchy.
Eg. PolygonMarkerPrimitive2D can be decomposed to 2 hairlines
PolyPolygonHairlinePrimitive2D's, each with different color.

Processor - a class that goes through the hierarchy of the Primitives, and
renders it some way.  Various processors, like VclPixelProcessor2D (renders to
the screen), VclMetafileProcessor2D (renders to the VCL metafile, eg. for
printing), etc.

== How to Implement a new Primitive ("something new to draw") ==

* Create an ancestor of BasePrimitive2D
  (or of its ancestor if it fits the purpose better)

  * Assign it an ID [in drawinglayer_primitivetypes2d.hxx]

  * Implement its decomposition
    [virtual Primitive2DSequence create2DDecomposition(...)]

* Extend the (various) processor(s)
  If you need more than relying on just the decomposition

== Where is DrawingLayer used ==

* SdrObject(s) (rectangles, Circles, predefined shapes etc.)

* Selections

* Various smaller cases to 'just draw something'

  * Draw to a virtual device, and use the resulting bitmap (like the example
    above)

* Custom widgets (like the Header / Footer indicator button)