Searched +hist:57 +hist:e24888 (Results 1 - 3 of 3) sorted by relevance
/haiku/src/servers/app/drawing/Painter/drawing_modes/ | ||
H A D | PixelFormat.h | diff 57e24888 Sun Jan 13 03:04:37 MST 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> diff 57e24888 Sun Jan 13 03:04:37 MST 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> |
H A D | PixelFormat.cpp | diff 57e24888 Sun Jan 13 03:04:37 MST 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> diff 57e24888 Sun Jan 13 03:04:37 MST 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> |
/haiku/src/servers/app/drawing/Painter/ | ||
H A D | Painter.cpp | diff 57e24888 Sun Jan 13 03:04:37 MST 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> diff 57e24888 Sun Jan 13 03:04:37 MST 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> diff b4671beb Thu Feb 06 02:51:57 MST 2014 Stephan Aßmus <superstippi@gmx.de> Regard Painter's transformation when rendering text. diff fe34b199 Sat Aug 23 08:30:57 MDT 2008 Stephan Aßmus <superstippi@gmx.de> * Fixed bug with cropped scaled bitmaps, the wrong offset was used. This fixes a regression in MediaPlayers peak display where the last row of pixels was wrong. * Fixed clipping rect bugs in the new bilinear scaling loops, the last row and/or columns don't always need special treatment, only if they map to the last row and/or column of the destination bitmap. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27177 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff ae3b2d5a Mon Jul 03 16:51:57 MDT 2006 Jérôme Duval <korli@users.berlios.de> reverting part of previous change, this was breaking the working part of scaling, still some bugs though git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18019 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff dd98ed8d Wed Apr 19 08:12:57 MDT 2006 Stephan Aßmus <superstippi@gmx.de> * implemented view bitmap options (B_BITMAP_TILE...) in ViewLayer (for example, fixes NetPositive rendering HTML with a background image) * use BRegion pool everywhere in ViewLayer * WindowLayer update sessions distinguish between different reasons for the update: exposed and requested - on expose updates, the view backgrounds are cleared immidiately (as on R5), to keep the time previous stuff keeps showing as short as possible, while on requested updates, the background clearing is delayed until the client draws something, to keep the time until the client fills a view with content as small as possible to reduce flickering (might need more work, could be buggy yet) * HWInterface and DrawingEngine support delayed syncing to the graphics hardware at least for FillRect/Region. The speed up gained by this is minor though. * HWInterface cursor rendering uses a bit of rounding to avoid the slight transparent shadow around the cursor (I don't know if it is fully correct though, at least the shasow disappeared) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17172 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 1fce337f Fri Dec 30 16:41:57 MST 2005 Stephan Aßmus <superstippi@gmx.de> cleaned up the code using templates and added optimized version for CMAP8 bitmaps and B_OP_OVER (to benefit Tracker) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15760 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 208e6678 Fri Dec 23 08:57:55 MST 2005 Stephan Aßmus <superstippi@gmx.de> small efficiency improvements - overall, the drawing speed of a usual BView, especially controls, is pretty much equal to R5 now (Drawing straight text, using StringWidth(), tons of AddLine()s, FillRect() etc) :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15662 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff d3b0b7b9 Tue Mar 29 15:57:43 MST 2005 Stephan Aßmus <superstippi@gmx.de> fixed some font related problems, Painter should now rely on the app_server font manager. maybe I fixed some compile problems too. Sorry if that was the case. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12144 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff b4671bebcf6244601660d4b89388b5eb9f91f921 Thu Feb 06 02:51:57 MST 2014 Stephan Aßmus <superstippi@gmx.de> Regard Painter's transformation when rendering text. |
Completed in 97 milliseconds