Searched +hist:57 +hist:e24888 (Results 1 - 3 of 3) sorted by relevance

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