Opened 11 years ago

Closed 11 years ago

#2209 closed bug (fixed)

Input method draws converting strings dirty

Reported by: shinta Owned by: jackburton
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no 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: hrev25124+ SHINTA

Attachments (4)

IM.png (10.9 KB) - added by shinta 11 years ago.
TextView.diff.bad (4.5 KB) - added by shinta 11 years ago.
TextView.diff (3.9 KB) - added by shinta 11 years ago.
TextView-stippi.diff (941 bytes) - added by stippi 11 years ago.
Alternative fix

Download all attachments as: .zip

Change History (13)

Changed 11 years ago by shinta

Attachment: IM.png added

comment:1 Changed 11 years ago by koki

Cc: koki added

Changed 11 years ago by shinta

Attachment: TextView.diff.bad added

comment:2 Changed 11 years ago by shinta

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

Changed 11 years ago by shinta

Attachment: TextView.diff added

comment:3 Changed 11 years ago by shinta

I rewrited patch.

TextView.diff should fix this problem.

comment:4 Changed 11 years ago by axeld

Owner: changed from axeld to jackburton

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

comment:5 Changed 11 years ago 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.

comment:6 Changed 11 years ago 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.

Changed 11 years ago by stippi

Attachment: TextView-stippi.diff added

Alternative fix

comment:7 Changed 11 years ago by stippi

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

comment:8 Changed 11 years ago by shinta

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

Thank you.

comment:9 Changed 11 years ago by stippi

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.