#
59e13a3f |
|
03-Aug-2008 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
fa6a00c6 |
|
10-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
00c81869 |
|
21-Jun-2008 |
Michael Lotz <mmlr@mlotz.ch> |
Fix obviously swapped if statement checking for a solid pattern. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26071 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d39634ce |
|
14-Sep-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* on R5, the meaning of B_CONSTANT_ALPHA is a bit different with regards to drawing bitmaps with alpha channel, instead of ignoring the bitmap alpha channel, it is further multiplied with the high color alpha channel, so basically, you can use the high color alpha as a "global" alpha value to draw the bitmap with * removed some duplicate code git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18843 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7e07723e |
|
05-May-2006 |
Stephan Aßmus <superstippi@gmx.de> |
added tracking the usage of the special B_OP_COPY version for text git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17326 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b6a33e1d |
|
12-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
f5b6cf65 |
|
28-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
de0283f0 |
|
20-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
forgot to commit the heart of the new drawing_mode implementation. Sorry about that, guys. Thou shalt use svn status after doing huge changes... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15600 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
59e13a3f06eedbc797f797da71c6810634b22cd4 |
|
03-Aug-2008 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
fa6a00c628f07c0310bbc97db6e69aca68461b82 |
|
10-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
00c81869c5fb67fcba61b5d41efb7081e6aec874 |
|
21-Jun-2008 |
Michael Lotz <mmlr@mlotz.ch> |
Fix obviously swapped if statement checking for a solid pattern. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26071 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d39634ce4d1fdf63e3515dc0f42b4fb0414bdb5e |
|
14-Sep-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* on R5, the meaning of B_CONSTANT_ALPHA is a bit different with regards to drawing bitmaps with alpha channel, instead of ignoring the bitmap alpha channel, it is further multiplied with the high color alpha channel, so basically, you can use the high color alpha as a "global" alpha value to draw the bitmap with * removed some duplicate code git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18843 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7e07723e686260f4e0a039e7b03418be17a5e5d3 |
|
05-May-2006 |
Stephan Aßmus <superstippi@gmx.de> |
added tracking the usage of the special B_OP_COPY version for text git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17326 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b6a33e1d41f7e77f5d1fdec054adf03fd2b97464 |
|
12-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
f5b6cf65b27a78f055c668b11f03ed6e3187c775 |
|
28-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
de0283f0f1f1b0100062f7515e9eb3dd101ada6b |
|
20-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
forgot to commit the heart of the new drawing_mode implementation. Sorry about that, guys. Thou shalt use svn status after doing huge changes... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15600 a95241bf-73f2-0310-859d-f6bbb57e9c96
|