[haiku-commits] Change in ...haiku[master]: Get rid of special B_OP_COPY implementation for rendering text

  • From: Gerrit <review@xxxxxxxxxxxxxxxxxxx>
  • To: waddlesplash <waddlesplash@xxxxxxxxx>, haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 13 Jan 2019 10:19:08 +0000

From Stephan Aßmus <superstippi@xxxxxx>:

Stephan Aßmus has uploaded this change for review. ( 
https://review.haiku-os.org/c/haiku/+/877


Change subject: Get rid of special B_OP_COPY implementation for rendering text
......................................................................

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.
---
M src/servers/app/drawing/Painter/Painter.cpp
D src/servers/app/drawing/Painter/drawing_modes/DrawingModeCopyText.h
D src/servers/app/drawing/Painter/drawing_modes/DrawingModeCopyTextSUBPIX.h
M src/servers/app/drawing/Painter/drawing_modes/PixelFormat.cpp
M src/servers/app/drawing/Painter/drawing_modes/PixelFormat.h
5 files changed, 7 insertions(+), 225 deletions(-)



  git pull ssh://git.haiku-os.org/haiku refs/changes/77/877/1
--
To view, visit https://review.haiku-os.org/c/haiku/+/877
To unsubscribe, or for help writing mail filters, visit 
https://review.haiku-os.org/settings

Gerrit-Project: haiku
Gerrit-Branch: master
Gerrit-Change-Id: I4348902ae754507f1429e0a9575f03d8ecbce333
Gerrit-Change-Number: 877
Gerrit-PatchSet: 1
Gerrit-Owner: Stephan Aßmus <superstippi@xxxxxx>
Gerrit-MessageType: newchange

Other related posts:

  • » [haiku-commits] Change in ...haiku[master]: Get rid of special B_OP_COPY implementation for rendering text - Gerrit