#
9a7906ea |
|
31-Jan-2022 |
Máximo Castañeda <antiswen@yahoo.es> |
PatternHandler: remove unused code hrev17117 implemented B_OP_COPY with a special treatment for text. hrev21929 introduced the color cache to speed up that text drawing. hrev52753 removed the special treatment of text in B_OP_COPY, but left the color cache and the text flag behind. Change-Id: Ib506c80a660e829132bce3ec1cb354fcfbab266c Reviewed-on: https://review.haiku-os.org/c/haiku/+/4931 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
97bd6fe8 |
|
19-Jun-2020 |
Kacper Kasper <kacperkasper@gmail.com> |
app_server: Implement more composition modes * Use agg::comp_op classes to blend pixels. * Subpixel path not implemented. * Needed by WebKit. * Implements #10274. Change-Id: I07b0002196fd0a05fc100bd9f6d703c33cadc85b Reviewed-on: https://review.haiku-os.org/c/haiku/+/2932 Reviewed-by: X512 <danger_mail@list.ru> Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
57e24888 |
|
13-Jan-2019 |
Stephan Aßmus <superstippi@gmx.de> |
Get rid of special B_OP_COPY implementation for rendering text Since BeOS had no anti-aliased drawing except for text, it didn't matter whether drawing diagonal lines (for example) in B_OP_COPY or B_OP_OVER. Applying the meaning of B_OP_COPY strictly to everything else would have broken pretty much every existing BeOS, resulting in broken drawing for anything but straight lines and rectangles. The solution was to treat B_OP_COPY just like B_OP_OVER *except* for text rendering, where we could be compatible with the BeOS behavior. Nevertheless, one can sometimes observe apps using B_OP_COPY where they /should/ be using B_OP_OVER for rendering text, resulting in white edges around the glyphs where the actual LowColor() does not match the current background on which the text is rendered. There is however a problem when glyphs in a string overlap. Some fonts have overlapping glyphs by default (handwriting, etc). With the LCD sub-pixel filtering, this problem is visible even in fonts where glyphs don't overlap normally, for example 'lt'. The leftmost pixel of the 't' is smeared due to the filtering and produces an almost transparent pixel which is rendered (using the low color as the background) on top of the 'l'. To fix this, one would have to render the string into an alpha mask buffer first, and then blend it all at once using B_OP_COPY. This however defeats the point of B_OP_COPY, which is to be a performance optimization. So instead, I opted for the solution that is already in place for everything else, which is to make B_OP_COPY behave like B_OP_OVER. For the case that this would have produced a difference, i.e. rendering with the solid high color, one needs to clear the background using the low color, before rendering text, or it would have looked broken. So in practice, there cannot be a difference. Change-Id: I4348902ae754507f1429e0a9575f03d8ecbce333 Reviewed-on: https://review.haiku-os.org/c/877 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
801b5d21 |
|
14-Aug-2015 |
Julian Harnath <julian.harnath@rwth-aachen.de> |
app_server: add pixel alpha composite solid mode * Same concept as the previously exisiting drawing mode implementations for e.g. pixel alpha overlay mode: when pattern is solid, provide a separate mode implementation which does no unnecessary pattern pixel lookups. This provides a considerable speedup in composite mode when no stipple pattern is used.
|
#
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
|