office-gobmx/canvas
Jan-Marek Glogowski 194e7ce17a tdf#40534 correctly match page with memory slab
LO has a page manager to match system memory backbuffers with
graphics memory on DX accelerated Windows. Internally this uses
an other rectangle implementation, the SurfaceRect, which had
some great comments like:

// a size of [0,0] therefore denotes a one-by-one rectangle.

In commit 230dbe2e43 ("#144866# Add
one pixel border around textures, a bunch of drivers clobber those
with dirt), the allocation was increased by a pixel border, but
this doesn't work correctly, because now an allocation of the
page size wouldn't fit anymore into a page, because the pages size
is decreased before comparison. In the end the mixup suffered from
hard to handle off-by-one problems.

This patch fixes the bug, but eventually SurfaceRect should be
replaced by an extended basegfx::B2IBox. But since B2IBox uses two
ranges, instead of a point and a size, it would need a lot of
conversations to I2Point and I2Size objects with the current
Page::insert algorithm.

Change-Id: Ia725b4f8ed4fb270f2eb3734e492062bc7f13793
Reviewed-on: https://gerrit.libreoffice.org/80628
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-10-11 17:32:57 +02:00
..
opengl
source tdf#40534 correctly match page with memory slab 2019-10-11 17:32:57 +02:00
workben
Executable_canvasdemo.mk
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

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.