Searched +hist:4 +hist:da1508a (Results 1 - 1 of 1) sorted by relevance
| /haiku/src/servers/app/drawing/Painter/ | ||
| H A D | Painter.cpp | diff e1965013 Mon Jul 28 15:30:26 MDT 2008 Stephan Aßmus <superstippi@gmx.de> The Y check can be moved out of the loop of course, why didn't I see this before?! Is about 4% faster than before. If anyone sees a way to make it faster yet, please shoot! I can watch movies fullscreen on a 2 GHz Core 2 Duo in VESA with bilinear scaling, but it would be nice to use less CPU... :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26667 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 2de437fa Fri Dec 30 14:31:36 MST 2005 Stephan Aßmus <superstippi@gmx.de> The first stab at optimizing bitmap drawing, with quite good results I might add. Drawing B_RGB32 bitmaps is more than 1.2 times faster than on R5, while B_CMAP8 bitmaps are slightly slower. The optimization is only for B_OP_COPY and unscaled bitmaps (B_RGB32 and B_CMAP8). Drawing only parts of the bitmap is supported. Adding optimization for scaled bitmaps should be beneficial, since the generic version is 2 two 4 times slower. I think it gets even worse for partial bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15758 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff f5b6cf65 Wed Dec 28 12:53:00 MST 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 diff 4da1508a Fri Apr 15 04:20:53 MDT 2005 Stephan Aßmus <superstippi@gmx.de> added convenience functions to PatternHandler and refactored the setting of the DrawingMode in Painter git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12408 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 4da1508a Fri Apr 15 04:20:53 MDT 2005 Stephan Aßmus <superstippi@gmx.de> added convenience functions to PatternHandler and refactored the setting of the DrawingMode in Painter git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12408 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff e196501316ab1f2c0b1ece664af6b508abfe9006 Mon Jul 28 15:30:26 MDT 2008 Stephan Aßmus <superstippi@gmx.de> The Y check can be moved out of the loop of course, why didn't I see this before?! Is about 4% faster than before. If anyone sees a way to make it faster yet, please shoot! I can watch movies fullscreen on a 2 GHz Core 2 Duo in VESA with bilinear scaling, but it would be nice to use less CPU... :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26667 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 2de437fa298867d1b054574e2e5f4f0003c27397 Fri Dec 30 14:31:36 MST 2005 Stephan Aßmus <superstippi@gmx.de> The first stab at optimizing bitmap drawing, with quite good results I might add. Drawing B_RGB32 bitmaps is more than 1.2 times faster than on R5, while B_CMAP8 bitmaps are slightly slower. The optimization is only for B_OP_COPY and unscaled bitmaps (B_RGB32 and B_CMAP8). Drawing only parts of the bitmap is supported. Adding optimization for scaled bitmaps should be beneficial, since the generic version is 2 two 4 times slower. I think it gets even worse for partial bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15758 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff f5b6cf65b27a78f055c668b11f03ed6e3187c775 Wed Dec 28 12:53:00 MST 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 diff 4da1508aa9f39f43b115517dbc09ff228b5cdacb Fri Apr 15 04:20:53 MDT 2005 Stephan Aßmus <superstippi@gmx.de> added convenience functions to PatternHandler and refactored the setting of the DrawingMode in Painter git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12408 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 115 milliseconds