Closed Bug 332497 Opened 19 years ago Closed 17 years ago

Slow japanese text selection

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: nikolakocicbz, Assigned: pavlov)

References

Details

(Keywords: perf, Whiteboard: cairo)

Attachments

(2 files, 1 obsolete file)

Japanese text
(deleted), text/html
Details
testcase2
(deleted), text/html; charset=UTF-8
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1 There is delay when selecting Japanese text and high CPU usage during selection. Reproducible: Always Steps to Reproduce: 1. Select text in testcase Actual Results: Selecting is slow Expected Results: Selecting is normal (like english letters)
Attached file Japanese text (deleted) —
Component: General → GFX: Thebes
Product: Firefox → Core
Version: unspecified → Trunk
Summary: Slow down when selecting Japanese text → Slow japanese text selection
Confirmed. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1 ID:2006033104
Whiteboard: cairo
Maybe, this is a regression of bug 328940 that is critical problem on some CJK web sites. I have an idea for better fix it, but maybe the patch that is creating now does not fix the performance issue...
I think that you cannot reproduce this bug on testcase2.
Oops. Sorry. Maybe, 3/31 build doesn't have a patch of bug 328940, so it's not a regression. But I think that the performance issue should be fixed... Nikora and Regis: Do you have many fonts on your system, right?
It seems that when there is <html lang="ja"> (Testcase2), selection works normaly, but when there is only <html> (Testcase1), selection works slowly.
I cannot reproduce it, but maybe this happen.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Both testcases select extremely slow, it is very obvious.
Slow = 3 seconds with a 1400 Mhrz processor.
Ria: Are you setting vaild Japanese font in 'Japanese Default Font'? If not so, it's not a bug...
I don't see Japanese fonts. In non-cairo builds I see question marks and I can select them instantly. In cairo builds I see squares and those take very long to select.
Ria: Thanks, but it's not a this bug.(generally, it may be same, but I think that it cannot fix...)
Kimura-san: Are you having some ideas for this?
(In reply to comment #6) > Nikora and Regis: > > Do you have many fonts on your system, right? Yes. Strangly I cannot reproduce today with testcases??? But I can reproduce at http://forums.mozillazine.org/viewtopic.php?p=2181864#2181864 And after visiting url below, testcases are working... I'm lost.
I can reproduce with the first testcase but not the second (as expected). I have East Asian font support installed so I see correct Japanese characters. (I also have complex script support installed, 310 fonts installed, ClearType enabled, and my system locale set to Japanese, in case those things are relevant.) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060407 Firefox/3.0a1 ID:2006040704
QA Contact: general → thebes
(In reply to comment #11) > Are you setting vaild Japanese font in 'Japanese Default Font'? > If not so, it's not a bug... Even if Ria didn't, it should be reasonably fast. Note that a non-cairo build doesn't have this problem (comment #12) probably because its font/glyph search logic is far better than that of the current trunk. (ref. bug 334299, bug 334296). Comment #16 is another indicator that the font search/fallback logic of the current trunk is not as good as that of Gfx:Win. Even without 'lang' specified, we should perform decently.
Blocks: 334719
i can reproduce. will profile shortly
Attached patch fix (obsolete) (deleted) — — Splinter Review
this patch makes it so that we hold on to the fallback font between script items. we'll still try the other fonts listed first, then try the old fallback font for the previous characters, and then try to find a fallback for the new characters. this speeds up measuring things where we get lots of script items and they all have to use a fallback font.
Assignee: nobody → pavlov
Status: NEW → ASSIGNED
Attachment #219107 - Flags: review?(vladimir)
Comment on attachment 219107 [details] [diff] [review] fix Looks fine, as long as: >- length = NSToCoordRound(len.cx * cairoToPixels); >+ length = len.cx * cairoToPixels; is intentional -- is this supposed to be part of this fix?
Attachment #219107 - Flags: review?(vladimir) → review+
checked in fix
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Backed out pending investigation with 334919; the if statements at the end of the patch are maybe going into an infinite loop? Since the flow is: if (currentFont == mFallbackFont) mFallbackFont = FindFallback(...) if (mFallbackFont && currentFont != mFallbackFont) currentFont = fallbackfont goto loop when we get through the loop again currentFont == fallbackfont, what will FindFallbackFont return? NULL if it can't find another one? or will it create a new fallback font?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 340590
Comment on attachment 219107 [details] [diff] [review] fix this patch was backed out/not checked back in and has been obsoleted.
Attachment #219107 - Attachment is obsolete: true
Attachment #219107 - Flags: review+
this bug should be mostly better with the checkin for 340590 -- need to test some more. Another issue with this testcase si that we don't chose the same fonts as we do for testcase2. leaving open for now
I'm still getting the same behavior as before, selecting the first testcase is slow and selecting the second testcase is fast.
this is really fast for me now.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: