Searched +hist:4423855 +hist:c (Results 1 - 3 of 3) sorted by relevance
/haiku/src/servers/app/drawing/ | ||
H A D | DrawingEngine.h | diff 77870621 Wed Oct 20 22:09:28 MDT 2021 Augustin Cavalier <waddlesplash@gmail.com> app_server: Drop gfxcpy and implement some TODOs about checking for graphics memory. We still do not know if the accelerant buffers are graphics memory or not, but in my testing (on the VESA driver), the only time I could get _CopyRect to be called was where the buffer was in fact not graphics memory. So that should provide a performance improvement there. On the other end of things, this should resolve unaligned video memory access problems on RISCV, and potentially other platforms, as gfxcpy32 did not attempt to align pointers; it should also improve performance as memcpy will usually be faster than our custom gfxcpy here. Most of this code has not been touched since 2006 or so. Change-Id: I40b0345c5d47f2b45acafb14f03fd3a24d2042a8 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4315 Reviewed-by: waddlesplash <waddlesplash@gmail.com> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> diff ebe6011c Fri Dec 11 16:35:56 MST 2020 X512 <danger_mail@list.ru> app_server: do not flush back buffer outside of clipping Introduce DrawTransaction that automatically hide/show floating overlays and flush back buffer. Fixes #15574. Change-Id: I30088b74fc66cfcd5b2b433b34141e7d496f68a1 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3496 Reviewed-by: Axel Dörfler <axeld@pinc-software.de> diff d99d8dbd Thu Aug 27 05:00:10 MDT 2020 X512 <danger_mail@list.ru> app_server memory management: use ObjectDeleter to mark ownership Make object ownership explicit by use of ObjectDeleter where possible. Change-Id: I499a00aa3390d1510ae284419e73faffa5166430 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2695 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> diff 2e499128 Sun Jun 07 02:08:41 MDT 2020 X512 <danger_mail@list.ru> app_server: fix transformations in BPicture Fixes #16122, #16147. Change-Id: Iee7aa8a2325d34a526578a58507ea3690459c8d7 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2898 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff 2d69e313 Tue Jun 09 19:19:51 MDT 2020 waddlesplash <waddlesplash@gmail.com> Revert "app_server: fix transformations in BPicture" This reverts commit b8e5671d5318e59ad4e36f047940521d18d1f5ed. Reason for revert: Broke all builds. Change-Id: Ie7c5b4a3c877894a1dc49a9de7a19f79e7eb2ab7 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2897 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff b8e5671d Sun Jun 07 02:08:41 MDT 2020 X512 <danger_mail@list.ru> app_server: fix transformations in BPicture Fixes #16122, #16147. Change-Id: I16a38919d25836546389aff6093415eda781668f Reviewed-on: https://review.haiku-os.org/c/haiku/+/2889 Reviewed-by: Stephan Aßmus <superstippi@gmx.de> diff 4423855c Wed Sep 13 14:02:00 MDT 2006 Stephan Aßmus <superstippi@gmx.de> This is the kind of bug you can search for hours. At first, I suspected a concurency problem in the DrawingEngine, so there is some debugging stuff added, as well as some unnecessary locking removed there. The problem was in Painter though, in that certain functions adjusted clipping at the "rasterizer level", while some other functions didn't care about that. Now the clipping is consistently set at the rasterizer level (rough estimate to avoid scanline generation outside real clipping region bounds). There are a number of bugs fixed by this, I'm going to find out later, what their ticket numbers are... Mouse preflet draws the mouse now, Backgrounds preflet draws the screen reliably... probably more, anything to do with bitmaps, round rects and possibly ellipses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18828 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 4423855c Wed Sep 13 14:02:00 MDT 2006 Stephan Aßmus <superstippi@gmx.de> This is the kind of bug you can search for hours. At first, I suspected a concurency problem in the DrawingEngine, so there is some debugging stuff added, as well as some unnecessary locking removed there. The problem was in Painter though, in that certain functions adjusted clipping at the "rasterizer level", while some other functions didn't care about that. Now the clipping is consistently set at the rasterizer level (rough estimate to avoid scanline generation outside real clipping region bounds). There are a number of bugs fixed by this, I'm going to find out later, what their ticket numbers are... Mouse preflet draws the mouse now, Backgrounds preflet draws the screen reliably... probably more, anything to do with bitmaps, round rects and possibly ellipses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18828 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 4423855cbd5411b64deba32e8b58af8b9c708ab6 Wed Sep 13 14:02:00 MDT 2006 Stephan Aßmus <superstippi@gmx.de> This is the kind of bug you can search for hours. At first, I suspected a concurency problem in the DrawingEngine, so there is some debugging stuff added, as well as some unnecessary locking removed there. The problem was in Painter though, in that certain functions adjusted clipping at the "rasterizer level", while some other functions didn't care about that. Now the clipping is consistently set at the rasterizer level (rough estimate to avoid scanline generation outside real clipping region bounds). There are a number of bugs fixed by this, I'm going to find out later, what their ticket numbers are... Mouse preflet draws the mouse now, Backgrounds preflet draws the screen reliably... probably more, anything to do with bitmaps, round rects and possibly ellipses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18828 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
H A D | DrawingEngine.cpp | diff 9a7906ea Mon Jan 31 12:12:08 MST 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> diff 77870621 Wed Oct 20 22:09:28 MDT 2021 Augustin Cavalier <waddlesplash@gmail.com> app_server: Drop gfxcpy and implement some TODOs about checking for graphics memory. We still do not know if the accelerant buffers are graphics memory or not, but in my testing (on the VESA driver), the only time I could get _CopyRect to be called was where the buffer was in fact not graphics memory. So that should provide a performance improvement there. On the other end of things, this should resolve unaligned video memory access problems on RISCV, and potentially other platforms, as gfxcpy32 did not attempt to align pointers; it should also improve performance as memcpy will usually be faster than our custom gfxcpy here. Most of this code has not been touched since 2006 or so. Change-Id: I40b0345c5d47f2b45acafb14f03fd3a24d2042a8 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4315 Reviewed-by: waddlesplash <waddlesplash@gmail.com> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> diff ebe6011c Fri Dec 11 16:35:56 MST 2020 X512 <danger_mail@list.ru> app_server: do not flush back buffer outside of clipping Introduce DrawTransaction that automatically hide/show floating overlays and flush back buffer. Fixes #15574. Change-Id: I30088b74fc66cfcd5b2b433b34141e7d496f68a1 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3496 Reviewed-by: Axel Dörfler <axeld@pinc-software.de> diff d99d8dbd Thu Aug 27 05:00:10 MDT 2020 X512 <danger_mail@list.ru> app_server memory management: use ObjectDeleter to mark ownership Make object ownership explicit by use of ObjectDeleter where possible. Change-Id: I499a00aa3390d1510ae284419e73faffa5166430 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2695 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> diff 2e499128 Sun Jun 07 02:08:41 MDT 2020 X512 <danger_mail@list.ru> app_server: fix transformations in BPicture Fixes #16122, #16147. Change-Id: Iee7aa8a2325d34a526578a58507ea3690459c8d7 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2898 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff 2d69e313 Tue Jun 09 19:19:51 MDT 2020 waddlesplash <waddlesplash@gmail.com> Revert "app_server: fix transformations in BPicture" This reverts commit b8e5671d5318e59ad4e36f047940521d18d1f5ed. Reason for revert: Broke all builds. Change-Id: Ie7c5b4a3c877894a1dc49a9de7a19f79e7eb2ab7 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2897 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff b8e5671d Sun Jun 07 02:08:41 MDT 2020 X512 <danger_mail@list.ru> app_server: fix transformations in BPicture Fixes #16122, #16147. Change-Id: I16a38919d25836546389aff6093415eda781668f Reviewed-on: https://review.haiku-os.org/c/haiku/+/2889 Reviewed-by: Stephan Aßmus <superstippi@gmx.de> diff b5be469e Thu Aug 15 10:01:32 MDT 2019 Adrien Destugues <pulkomandy@pulkomandy.tk> app_server: some missing std::nothrow and error checks. I had app_server crash on me because of an uncaught allocation exception. I don't know if this will fix it but it's better to try to survive even if it may result in some UI glitches. Change-Id: I09dd2a7e6ff63d52f51389d7418d1a1d1810af00 Reviewed-on: https://review.haiku-os.org/c/haiku/+/1720 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f4c2f7eb Fri Jan 10 13:06:36 MST 2014 Jonathan Schleifer <js@webkeks.org> Remove variable length arrays of non-PODs. Variable length arrays of non-PODs are not part of the C++ standard, but a GNU extension that never worked correctly. Instead, BStackOrHeap array is used now, which makes sure that it's not too big for the stack, calls all constructors and is valid C++. diff f4c2f7eb Fri Jan 10 13:06:36 MST 2014 Jonathan Schleifer <js@webkeks.org> Remove variable length arrays of non-PODs. Variable length arrays of non-PODs are not part of the C++ standard, but a GNU extension that never worked correctly. Instead, BStackOrHeap array is used now, which makes sure that it's not too big for the stack, calls all constructors and is valid C++. |
/haiku/src/servers/app/drawing/Painter/ | ||
H A D | Painter.cpp | diff 5cd344f7 Sat Jun 24 14:27:38 MDT 2023 Niels Sascha Reedijk <niels.reedijk@gmail.com> app_server: fix order of initialization GCC 13 warns that the a pointer is taken from a member that according to the rules is not yet initialized. Fix the declaration and order of initialization to prevent us depending on undefined behavior. Change-Id: Iab4644c33a3a286e083450da0b3575acfe284f29 Reviewed-on: https://review.haiku-os.org/c/haiku/+/6650 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff 44233abf Fri May 05 11:08:09 MDT 2023 Máximo Castañeda <antiswen@yahoo.es> Painter: change to a solid pattern for gradients Gradients don't use patterns, but then some common drawing code makes decisions based on them. Let's set the pattern to B_SOLID_HIGH so that we get the expected result, in particular one that does not depend on the last pattern used by a previous operation. Fixes #18370. Change-Id: I9d71c6d334d77be8fe4783a072b8df519486d74e Reviewed-on: https://review.haiku-os.org/c/haiku/+/6416 Reviewed-by: John Scipione <jscipione@gmail.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: waddlesplash <waddlesplash@gmail.com> Reviewed-by: Stephan Aßmus <superstippi@gmx.de> diff 9a7906ea Mon Jan 31 12:12:08 MST 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> diff 1f357f79 Fri Feb 04 12:29:23 MST 2022 Máximo Castañeda <antiswen@yahoo.es> Painter: sync renderer color SetDrawState sets the pattern directly and then calls the member functions to update colors. As SetHighColor does not update the renderers if color does not change, that means we lose sync in some corner cases. Change-Id: I5f8771baa58643c559df243dcc1603983941faee Reviewed-on: https://review.haiku-os.org/c/haiku/+/4930 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: waddlesplash <waddlesplash@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 4423855c Wed Sep 13 14:02:00 MDT 2006 Stephan Aßmus <superstippi@gmx.de> This is the kind of bug you can search for hours. At first, I suspected a concurency problem in the DrawingEngine, so there is some debugging stuff added, as well as some unnecessary locking removed there. The problem was in Painter though, in that certain functions adjusted clipping at the "rasterizer level", while some other functions didn't care about that. Now the clipping is consistently set at the rasterizer level (rough estimate to avoid scanline generation outside real clipping region bounds). There are a number of bugs fixed by this, I'm going to find out later, what their ticket numbers are... Mouse preflet draws the mouse now, Backgrounds preflet draws the screen reliably... probably more, anything to do with bitmaps, round rects and possibly ellipses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18828 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 4423855c Wed Sep 13 14:02:00 MDT 2006 Stephan Aßmus <superstippi@gmx.de> This is the kind of bug you can search for hours. At first, I suspected a concurency problem in the DrawingEngine, so there is some debugging stuff added, as well as some unnecessary locking removed there. The problem was in Painter though, in that certain functions adjusted clipping at the "rasterizer level", while some other functions didn't care about that. Now the clipping is consistently set at the rasterizer level (rough estimate to avoid scanline generation outside real clipping region bounds). There are a number of bugs fixed by this, I'm going to find out later, what their ticket numbers are... Mouse preflet draws the mouse now, Backgrounds preflet draws the screen reliably... probably more, anything to do with bitmaps, round rects and possibly ellipses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18828 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 4423855cbd5411b64deba32e8b58af8b9c708ab6 Wed Sep 13 14:02:00 MDT 2006 Stephan Aßmus <superstippi@gmx.de> This is the kind of bug you can search for hours. At first, I suspected a concurency problem in the DrawingEngine, so there is some debugging stuff added, as well as some unnecessary locking removed there. The problem was in Painter though, in that certain functions adjusted clipping at the "rasterizer level", while some other functions didn't care about that. Now the clipping is consistently set at the rasterizer level (rough estimate to avoid scanline generation outside real clipping region bounds). There are a number of bugs fixed by this, I'm going to find out later, what their ticket numbers are... Mouse preflet draws the mouse now, Backgrounds preflet draws the screen reliably... probably more, anything to do with bitmaps, round rects and possibly ellipses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18828 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 223 milliseconds