Implemented using the transformation in Painter (incomplete)

* Also removed wonky BeOS rendering of stroked round rects and ellipses.
Nobody would expect it to work like this. This affects stroked round rects
and ellipsis with a pensize greater than 1.
* Refactored common code from _StrokePath() and _FillPath().
* _StrokePath() returned a curious bounding box that didn't take into
acount the miter width. Now the bounding box is computed from the actual
stroke conversion of the path.

Add Alpha Masking support in ClipToPicture

Use AGG to implement ClipToPicture in a faster and better way.
There are things missing in this initial implementation:
* No support for PushState/PopState saving and restoring the picture.
* No support for nested clipping through PushState
* The clipping doesn't happen where you expect it when using SetScale()
* There are artifacts when scrolling and resizing clipped views
* The implementation uses more memory than it needs, as the clipping
bitmap is stored as RGBA32, yet only the alpha channel is used
* The clipping bitmap is rendered more times than it needs to. We need
some caching here.

Patch by Artur Wyszynski:
* Implemented BGradient, BGradientLinear, BGradientRadial,
BGradientDiamond, BGradientConic and BGradientRadialFocus
new Interface Kit classes.
* Implemented all the (AGG-based) backend necessary in
the app_server to render gradients (Painter, DrawingEngine)
* app_server/View can convert a BGradient layout to screen
coordinates.
* Added BGradient methods of the Fill* methods in BView.
* Implemented a test app and added it to the image as a
demo.
* Adopted Icon-O-Matic and libs/icon in order to avoid
clashing with the new BGradient class. Re-use some
parts where possible.

Awesome work, Artur! Thanks a lot. Now a more modern
looking GUI has just become much easier to implement! :-)

TODO:
* Remove the need to have gradient type twice in the
app_server protocol.
* Refactor some parts of the patch to remove duplicated
code (Painter, DrawingEngine).
* Adopt the BPicture protocol to know about BGradients.
* Review some parts of the BArchivable implementation.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28109 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andrej Spielmann (GSoC):
* Simplified the subpixel related methods for the AGG "pixel format" template
interface, the ones for the solid cover simply pass through the existing
methods, so only one subpixel blending function is left which does the actual
work (this removes a lot of the previously added code)
* Implemented a new rasterizer based on the original AGG rasterizer which
implements subpixel anti-aliasing for any generic AGG vector pipelines. It
is now optionally used in Painter and AGGTextRenderer (for vector fonts, ie
rotated, sheared or big enough fonts) depending on the global subpixel
setting.
* Put all subpixel variables into the new GlobalSubpixelSettings.h|cpp
* Simplified DesktopSettings related classes a bit and renamed previous
FontSubpixelAntialiasing to just SubpixelAntialiasing.
* The private libbe functions for subpixel related settings moved from Font.cpp
to InterfaceDefs.cpp where other such functions live. They are not related
to fonts only anymore.
* Removed the subpixel related settings again from the Fonts preflet and added
them to the Appearance preflet instead.

All of the above implements subpixel anti-aliasing on a global scale, which
to my knowledge no other OS is doing at the moment. Any vector rendering
can optionally use subpixel anti-aliasing in Haiku now. The bitmap cached fonts
are still affected by the Freetype complile time #define to enable the patented
subpixel rasterization (three times wide glyphs). Vector fonts and shapes are
not affected though at the moment.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26755 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andrej Spielmann (GSOC):
* Integrate the subpixel rendering with the existing drawing backend and
the font rendering.
* The font cache has got an additional rendering type for extracting and
caching glyph bitmaps that store subpixel coverage values.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26361 a95241bf-73f2-0310-859d-f6bbb57e9c96

* long overdue update to AGG 2.4
* removed the useless parts of AGG (which are only needed for the
interactive examples)
* make sure to jam -a libagg.a to solve any linking issues


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17838 a95241bf-73f2-0310-859d-f6bbb57e9c96

* removed the special font renderer which was actually
the same as the normal one (one less renderer to update
the color of)
* added a special B_OP_COPY implementation for text, which
is in fact what the implementation was until now, so
just like on R5, you have to specify the correct low color
or you will see artifacts for the anti-aliased pixels
* implemented B_OP_COPY just like B_OP_OVER (only it draws
the low color too like it should). So all apps that
used B_OP_COPY to draw anything can continue to do so
without having to worry about the low color, it will
be anti-aliased against the actual background instead of
the low color (which made especially no sense when drawing
with the low color). Although this change makes it a bit
slower to use B_OP_COPY, Haiku is now much more compatible.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17117 a95241bf-73f2-0310-859d-f6bbb57e9c96

* extracted the frame buffer memcpy routine from HWInterface.cpp
into a new frame_buffer_support.h
* added blend32 routine for blending a certain color with
a scanline in the frame buffer
* added "solid" versions of B_OP_ALPHA drawing with
B_ALPHA_OVERLAY alha function (blending on top of
a non-transparent background such as the frame buffer)
* implemented an optimized shortcut for alpha blended
FillRect() in Painter
* used the "packed" version of scanlines for shapes with
an outline thicker than 4 pixels (and filled shapes anyways),
this improves drawing speed when there are a few anti-aliased
pixels at the beginning of a scanline, then a solid fill and
some anti-aliased pixels at the end of the scanline. Such as
large letters.

To summarize: The alpha blending in Painter seems to be about
1.45 times faster than on BeOS R5 which benefits drawing large
shapes. For example, drawing a large alpha blended rounded rect
is 1.28 times faster on the Haiku app_server. On the other hand,
B_OP_COPY is quite tough to beat. It is currently 10 times faster
on R5. But a great deal seems to be caused by the Painter
rasterization algorithm itself, since commenting out the actual
drawing doesn't gain any speed.
The other useful experience I collected was that reading and
writing and over the PCI bus in the same loop really hurts
performance. It is actually faster (like 1.8 times!!) to allocate
a second buffer, read from frame buffer into that, doing the
blending at the same time, then writing the buffer back to the
screen.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15698 a95241bf-73f2-0310-859d-f6bbb57e9c96

complete rework of the drawing_modes implementation... I achieved a speedup of 8 to 9 times, tested with text rendering. Believe it or not, but the Haiku text rendering is now faster than R5 for B_OP_COPY at least. And there is quite some room for improvement yet. (faster text bounding box calculation, avoiding the double UTF8 conversion, etc)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15596 a95241bf-73f2-0310-859d-f6bbb57e9c96

added license headers

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12817 a95241bf-73f2-0310-859d-f6bbb57e9c96

define the use of the new BRegion AGG renderer

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12401 a95241bf-73f2-0310-859d-f6bbb57e9c96

moved Painter into drawing

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11989 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented using the transformation in Painter (incomplete)

* Also removed wonky BeOS rendering of stroked round rects and ellipses.
Nobody would expect it to work like this. This affects stroked round rects
and ellipsis with a pensize greater than 1.
* Refactored common code from _StrokePath() and _FillPath().
* _StrokePath() returned a curious bounding box that didn't take into
acount the miter width. Now the bounding box is computed from the actual
stroke conversion of the path.

Add Alpha Masking support in ClipToPicture

Use AGG to implement ClipToPicture in a faster and better way.
There are things missing in this initial implementation:
* No support for PushState/PopState saving and restoring the picture.
* No support for nested clipping through PushState
* The clipping doesn't happen where you expect it when using SetScale()
* There are artifacts when scrolling and resizing clipped views
* The implementation uses more memory than it needs, as the clipping
bitmap is stored as RGBA32, yet only the alpha channel is used
* The clipping bitmap is rendered more times than it needs to. We need
some caching here.

Patch by Artur Wyszynski:
* Implemented BGradient, BGradientLinear, BGradientRadial,
BGradientDiamond, BGradientConic and BGradientRadialFocus
new Interface Kit classes.
* Implemented all the (AGG-based) backend necessary in
the app_server to render gradients (Painter, DrawingEngine)
* app_server/View can convert a BGradient layout to screen
coordinates.
* Added BGradient methods of the Fill* methods in BView.
* Implemented a test app and added it to the image as a
demo.
* Adopted Icon-O-Matic and libs/icon in order to avoid
clashing with the new BGradient class. Re-use some
parts where possible.

Awesome work, Artur! Thanks a lot. Now a more modern
looking GUI has just become much easier to implement! :-)

TODO:
* Remove the need to have gradient type twice in the
app_server protocol.
* Refactor some parts of the patch to remove duplicated
code (Painter, DrawingEngine).
* Adopt the BPicture protocol to know about BGradients.
* Review some parts of the BArchivable implementation.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28109 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andrej Spielmann (GSoC):
* Simplified the subpixel related methods for the AGG "pixel format" template
interface, the ones for the solid cover simply pass through the existing
methods, so only one subpixel blending function is left which does the actual
work (this removes a lot of the previously added code)
* Implemented a new rasterizer based on the original AGG rasterizer which
implements subpixel anti-aliasing for any generic AGG vector pipelines. It
is now optionally used in Painter and AGGTextRenderer (for vector fonts, ie
rotated, sheared or big enough fonts) depending on the global subpixel
setting.
* Put all subpixel variables into the new GlobalSubpixelSettings.h|cpp
* Simplified DesktopSettings related classes a bit and renamed previous
FontSubpixelAntialiasing to just SubpixelAntialiasing.
* The private libbe functions for subpixel related settings moved from Font.cpp
to InterfaceDefs.cpp where other such functions live. They are not related
to fonts only anymore.
* Removed the subpixel related settings again from the Fonts preflet and added
them to the Appearance preflet instead.

All of the above implements subpixel anti-aliasing on a global scale, which
to my knowledge no other OS is doing at the moment. Any vector rendering
can optionally use subpixel anti-aliasing in Haiku now. The bitmap cached fonts
are still affected by the Freetype complile time #define to enable the patented
subpixel rasterization (three times wide glyphs). Vector fonts and shapes are
not affected though at the moment.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26755 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andrej Spielmann (GSOC):
* Integrate the subpixel rendering with the existing drawing backend and
the font rendering.
* The font cache has got an additional rendering type for extracting and
caching glyph bitmaps that store subpixel coverage values.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26361 a95241bf-73f2-0310-859d-f6bbb57e9c96

* long overdue update to AGG 2.4
* removed the useless parts of AGG (which are only needed for the
interactive examples)
* make sure to jam -a libagg.a to solve any linking issues


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17838 a95241bf-73f2-0310-859d-f6bbb57e9c96

* removed the special font renderer which was actually
the same as the normal one (one less renderer to update
the color of)
* added a special B_OP_COPY implementation for text, which
is in fact what the implementation was until now, so
just like on R5, you have to specify the correct low color
or you will see artifacts for the anti-aliased pixels
* implemented B_OP_COPY just like B_OP_OVER (only it draws
the low color too like it should). So all apps that
used B_OP_COPY to draw anything can continue to do so
without having to worry about the low color, it will
be anti-aliased against the actual background instead of
the low color (which made especially no sense when drawing
with the low color). Although this change makes it a bit
slower to use B_OP_COPY, Haiku is now much more compatible.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17117 a95241bf-73f2-0310-859d-f6bbb57e9c96

* extracted the frame buffer memcpy routine from HWInterface.cpp
into a new frame_buffer_support.h
* added blend32 routine for blending a certain color with
a scanline in the frame buffer
* added "solid" versions of B_OP_ALPHA drawing with
B_ALPHA_OVERLAY alha function (blending on top of
a non-transparent background such as the frame buffer)
* implemented an optimized shortcut for alpha blended
FillRect() in Painter
* used the "packed" version of scanlines for shapes with
an outline thicker than 4 pixels (and filled shapes anyways),
this improves drawing speed when there are a few anti-aliased
pixels at the beginning of a scanline, then a solid fill and
some anti-aliased pixels at the end of the scanline. Such as
large letters.

To summarize: The alpha blending in Painter seems to be about
1.45 times faster than on BeOS R5 which benefits drawing large
shapes. For example, drawing a large alpha blended rounded rect
is 1.28 times faster on the Haiku app_server. On the other hand,
B_OP_COPY is quite tough to beat. It is currently 10 times faster
on R5. But a great deal seems to be caused by the Painter
rasterization algorithm itself, since commenting out the actual
drawing doesn't gain any speed.
The other useful experience I collected was that reading and
writing and over the PCI bus in the same loop really hurts
performance. It is actually faster (like 1.8 times!!) to allocate
a second buffer, read from frame buffer into that, doing the
blending at the same time, then writing the buffer back to the
screen.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15698 a95241bf-73f2-0310-859d-f6bbb57e9c96

complete rework of the drawing_modes implementation... I achieved a speedup of 8 to 9 times, tested with text rendering. Believe it or not, but the Haiku text rendering is now faster than R5 for B_OP_COPY at least. And there is quite some room for improvement yet. (faster text bounding box calculation, avoiding the double UTF8 conversion, etc)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15596 a95241bf-73f2-0310-859d-f6bbb57e9c96

added license headers

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12817 a95241bf-73f2-0310-859d-f6bbb57e9c96

define the use of the new BRegion AGG renderer

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12401 a95241bf-73f2-0310-859d-f6bbb57e9c96

moved Painter into drawing

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11989 a95241bf-73f2-0310-859d-f6bbb57e9c96