Searched +hist:4423855 +hist:c (Results 1 - 3 of 3) sorted by relevance

/haiku/src/servers/app/drawing/
H A DDrawingEngine.hdiff 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 DDrawingEngine.cppdiff 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 DPainter.cppdiff 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