strepsirrhini/office-gobmx
9
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
office-gobmx/canvas
History
Stephan Bergmann 7e403195e5 Introduce o3tl::optional as an alias for std::optional 
...with a boost::optional fallback for Xcode < 10 (as std::optional is only
available starting with Xcode 10 according to
<https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS
and macOS is still Xcode 9.3 according to README.md).  And mechanically rewrite
all code to use o3tl::optional instead of boost::optional.

One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per
fed7c3deb3 "Slience bogus
-Werror=maybe-uninitialized" should no longer be necessary (and whose check
happened to no longer trigger for GCC 10 trunk, even though that compiler would
still emit bogus -Wmaybe-uninitialized for uses of boost::optional under
--enable-optimized, which made me ponder whether this switch from
boost::optional to std::optional would be a useful thing to do; I keep that
configure.ac check for now, though, and will only remove it in a follow up
commit).

Another longer-term benefit is that the code is now already in good shape for an
eventual switch to std::optional (a switch we would have done anyway once we no
longer need to support Xcode < 10).

Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses
boost::property_tree::ptree::get_child_optional returning boost::optional, so
let it keep using boost::optional for now.

After a number of preceding commits have paved the way for this change, this
commit is completely mechanical, done with

> git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g'

(before committing include/o3tl/optional.hxx, and relying on some GNU features).
It excludes some files where mention of boost::optional et al should apparently
not be changed (and the sub-repo directory stubs).  It turned out that all uses
of boost::none across the code base were in combination with boost::optional, so
had all to be rewritten as o3tl::nullopt.

Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b
Reviewed-on: https://gerrit.libreoffice.org/84128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-01 14:57:16 +01:00
..
opengl
source Introduce o3tl::optional as an alias for std::optional 2019-12-01 14:57:16 +01:00
workben Remove unused DemoRenderer::maColorWhite 2019-11-26 22:16:32 +01:00
Executable_canvasdemo.mk
IwyuFilter_canvas.yaml tdf#42949 Fix IWYU warnings in canvas/*/*cxx 2019-11-06 14:23:21 +01:00
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
StaticLibrary_directxcanvas.mk

README 

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.