office-gobmx/canvas
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
opengl
source Make upcasting css::uno::Reference ctor require complete types 2020-04-27 07:19:30 +02:00
workben
Executable_canvasdemo.mk
IwyuFilter_canvas.yaml
Library_cairocanvas.mk
Library_canvasfactory.mk
Library_canvastools.mk
Library_directx9canvas.mk
Library_gdipluscanvas.mk
Library_oglcanvas.mk
Library_simplecanvas.mk
Library_vclcanvas.mk
Makefile
Module_canvas.mk
Package_opengl.mk
README
README.vars
StaticLibrary_directxcanvas.mk

UNO-based graphics backend, lesser impedance to modern graphics APIs
than vcl.

== The Canvas Framework ==

The canvas framework is the successor of the system GUI and graphics
backend VCL. Basic functionality is available, supplying just as much
features as necessary to provide a VCL-equivalent feature set (except
proper BiDi/CTL support).

The canvas framework consists of the following two modules, canvas and
cppcanvas. Additionally, a new generic graphics tooling is used (but
not exclusively by the canvas, Armin's drawinglayer module also make
use of it), which resides in basegfx.

The UNO API used by the canvas is primarily under
css::rendering, with css::rendering::XCanvas
being the central interface.

== The slideshow engine ==

The slideshow engine has replaced the former Impress-embedded
presentation framework with a fully independent UNO component, and it
is based on the canvas. Some features used there are only available
from canvas, like double-buffering, and hardware-accelerated
alpha-blending (currently not on all platforms).

== Cairo canvas ==

cairo canvas is one of backends of canvas component. canvas is mostly
used for slideshow rendering and also for emf+ rendering. we hoped it
will even be used by drawing layer, but it didn't happen (yet?) for
API look at offapi/com/sun/star/rendering/, the implementation is in
canvas and cppcanvas modules.

cairo canvas backend uses cairo library for rendering. main advantage
is support of alpha transparency and in some cases accelerated
rendering.

the backend itself is quite old and stable, not many changes in that
area lately, mostly changes for emf+ rendering, communication with
vcl and bugfixes

FUTURE work: look at cairo canvas and situation when it is used
(mostly slideshow). TODO there still might be more cases when we
can save some roundtrips when exchanging data with vcl.