| /haiku/src/servers/app/drawing/Painter/bitmap_painter/ |
| H A D | painter_bilinear_scale.nasm | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| H A D | BitmapPainter.h | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| H A D | DrawBitmapGeneric.h | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| H A D | DrawBitmapNearestNeighbor.h | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| H A D | DrawBitmapNoScale.h | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| H A D | BitmapPainter.cpp | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| H A D | DrawBitmapBilinear.h | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| /haiku/src/servers/app/drawing/Painter/ |
| H A D | PainterAggInterface.h | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| H A D | Jamfile | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| H A D | Painter.h | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|
| H A D | Painter.cpp | e353fe396a362ab9c10a7c058e76007939370f66 Mon Aug 03 21:32:07 UTC 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.
|