History log of /haiku/src/servers/app/drawing/Painter/bitmap_painter/DrawBitmapBilinear.h
Revision Date Author Comments
# 5ffbe7d7 30-Mar-2019 Augustin Cavalier <waddlesplash@gmail.com>

Change all references to "__INTEL__" to "__i386__".

They are functionally identical, but the former is a BeOS/Haiku-specfic
macro that we include in the compiler specs, and the latter is defined
by GCC.

# b0f4e518 18-Nov-2015 Julian Harnath <julian.harnath@rwth-aachen.de>

app_server: fix gcc4 build

# 718f3528 18-Nov-2015 Julian Harnath <julian.harnath@rwth-aachen.de>

app_server: bitmap interpolation; fix out-of-bounds access

* Optimized code path for bitmap drawing with bilinear interpolation
scaling was assuming that source bitmap is always at least 2 rows
in size.

* Fixes #12469: in webkit, scaled 1-pixel-high bitmaps often occur.
If the bitmap allocation is by chance aligned to a page end, access
to the non-existant second row crashes app_server.

# 0a6baa7e 10-Nov-2015 Julian Harnath <julian.harnath@rwth-aachen.de>

app_server: gcc4 build fixes

# 64c6e038 14-Aug-2015 Julian Harnath <julian.harnath@rwth-aachen.de>

app_server: bilinear bitmap painting: alpha overlay support

* Add support for pixel alpha overlay mode in the optimized bilinear-
scaled bitmap drawing code of BitmapPainter.
For now, only BilinearDefault supports this. DrawBitmapBilinear
gets the colour type and draw mode as template parameters to
minimize code duplication and allow simple extension with further
pixel formats and modes.
Avoids, for this mode, fallback to the slower generic
AGG-pipeline-based version.

# e353fe39 03-Aug-2015 Julian Harnath <julian.harnath@rwth-aachen.de>

app_server Painter: refactoring, extract bitmap drawing

* Extract bitmap drawing from Painter into separate class
Painter::BitmapPainter. This will allow to add new optimized
drawing modes without making Painter larger.

* BitmapPainter itself is further decomposed into separate
(method object) structs per drawing mode (currently, those are:
generic, no scale, nearest neighbor, bilinear). New optimized
implementations can be added by writing additional method objects
and calling them from BitmapPainter.

* DrawBitmapNoScale and DrawBitmapBilinear are implemented using
CRTP. This removes the function pointer in the 'no scale' version,
which was previously used to select the row copy type. In the
bilinear version it untangles the three variants (default,
low filter ratio, SIMD) into separate methods.

* While BitmapPainter is a nested class in Painter, the specialized
method objects are not. Instead, the AGG-specific data fields from
Painter are moved into a new struct PainterAggInterface. This
struct is passed to the method objects and allows them to access
the Painter's AGG renderer/rasterizer/scanline containers/etc.

Alternatives would be to make all the involved structs friends
of Painter, or nesting them all, or exposing all of Painter's
internals via getter methods -- all of these would be quite messy.

The details of the bitmap painting implementations are
intentionally hidden from Painter: there is no need for it to
know about their internals -- it does not even know their type
names. (Nesting or making them friend would expose their type
names to Painter.)

Furthermore, there is another level of information hiding between
BitmapPainter and the DrawBitmap[...] method objects.
BitmapPainter itself only needs to decide that it uses e.g. the
bilinear version. It has no knowledge that DrawBitmapBilinear is
internally made out of several structs implementing specially
optimized versions.

* Refactoring only, no functional change intended. Performance
should be unaffected.