Ticket #2209 (closed bug: fixed)

Opened 1 week ago

Last modified 5 days ago

Input method draws converting strings dirty

Reported by: shinta Assigned to: jackburton
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1 development
Cc: koki Platform: x86

Description

Input methods (IM) like Canna IM draws converting strings (bgcolor = pink, blue) dirty. See the attached picture. I guess that BView's low color (view color?) is set to white, although should be set to pink, blue.

Haiku: r25124+
SHINTA

Attachments

IM.png (10.9 kB) - added by shinta on 05/04/08 11:36:15.
TextView.diff.bad (4.5 kB) - added by shinta on 05/05/08 02:07:19.
TextView.diff (3.9 kB) - added by shinta on 05/05/08 11:25:14.
TextView-stippi.diff (0.9 kB) - added by stippi on 05/07/08 08:44:55.
Alternative fix

Change History

05/04/08 11:36:15 changed by shinta

  • attachment IM.png added.

05/04/08 17:07:31 changed by koki

  • cc set to koki.

05/05/08 02:07:19 changed by shinta

  • attachment TextView.diff.bad added.

05/05/08 02:12:14 changed by shinta

I think string should be drawn separately (blue/red region) like attached patch. But, the patch has a bug on line breaking.

05/05/08 11:25:14 changed by shinta

  • attachment TextView.diff added.

05/05/08 11:27:47 changed by shinta

I rewrited patch.

TextView.diff should fix this problem.

05/05/08 13:29:28 changed by axeld

  • owner changed from axeld to jackburton.

Thanks! I'll assign this to Stefano for review, as he is our BTextView master :-)

05/07/08 08:31:17 changed by stippi

I have reviewed the patch and it looks fine to me. However, as I understand, all this is supposed to do is fix the bad text anti-aliasing. The patch adds considerable overhead just to be able to use B_OP_COPY text rendering (the only text rendering where the low color of the view is used regardless of the true background of the text). While B_OP_COPY rendering is indeed much faster, the added client-server communication in this patch should completely ruin any speed gains. Therefor, I would vote to keep the original code and simply add a view->SetDrawingMode(B_OP_OVER) before rendering the inputted text in order to make the text blend with the true background. This also makes the code easier to read, understand and extend.

05/07/08 08:33:11 changed by stippi

Oh, forgot to mention... there are a couple of issues with the patch as is: The drawing view is not used consistently, so with double buffered drawing, it would not work. And the added private function has a typo in it's name.

05/07/08 08:44:55 changed by stippi

  • attachment TextView-stippi.diff added.

Alternative fix

05/07/08 08:48:42 changed by stippi

SHINTA, could you have a look at my "Alternative Fix" patch? Does that solve the observed problem as well?

05/07/08 09:42:37 changed by shinta

stippi, your patch works well. It's simple!

Thank you.

05/07/08 10:40:37 changed by stippi

  • status changed from new to closed.
  • resolution set to fixed.

Thanks for the feedback (was unable to test). Thus fixed in r25349.