B_OP_COPY does not work as advertized anymore

[axeld]

This is a problem of how to deal with anti-aliasing. The current solution is to more or less ignore B_OP_COPY, and apply the aliasing by taking the destination into account.

However, this leads to unwanted results (namely the anti-aliased pixels get darker and darker with each redraw).

Just using this ticket as a discussion on how to solve this the best way.

[stippi]

Well, for a long time after the initial implementation, B_OP_COPY worked exactly as advertised for text rendering, only also for all the other primitives. Since you didn't need to be aware of the problem for other primitives on BeOS, existing apps usually do not set the low color to the correct color before stroking a line for example. Or they stroke a line using the low color onto a background of another color. Even for text rendering, many developers didn't get this right and you could often see text being rendered with the wrong background color, like a white low color onto an actually gray background. For all these reasons, I decided that B_OP_COPY only works as before for text rendering, for everything else, it works like B_OP_OVER. The draw-back is the one you describe in this ticket, but obviously it is a far less common problem than apps using B_OP_COPY in the wrong way because it didn't matter on R5. I leave it up to you to mark this as invalid or not. At least I don't really see a way to fix this, since app_server cannot tell if something would look bad or not and change behavior accordingly.

[tangobravo]

Does B_OP_COPY still work as advertised for text? I ask because I noticed the text in a tracker query seems to suffer from the anti-aliasing darkening when the window is resized.

Perhaps a solution would be to add a BView flag to enable anti-aliased primitives, which could be set by default in the Haiku headers so new apps would look nice, but would ensure R5 apps render as before. I suppose it's a choice between making most things look better, or shooting for exact pixel-for-pixel compatibility with R5 (not hugely important, IMHO)

Simon (back from BeGeistert and slowly catching up on Haiku stuff)

[korli]

It seems this affects the ticket #4251

[diver]

Does hrev52753 change anything wrt this ticket?

[stippi]

Yes, it creates the situation described now also for text. I think the ticket should be marked as invalid. I cannot imagine a situation in which this would be a problem. The background would have to not be cleared, but usually it is always cleared. In which situation does it make sense to draw exactly over what you have already drawn, versus marking invalid only those parts that need redrawing, but then drawing everything, including the background.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed