29092 2009-09-09 10:28:11 -0700 Performance slow when loading a large text html file on Symbian platform 2009-09-26 08:00:39 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) S60 Hardware S60 3rd edition RESOLVED FIXED P2 Normal --- 1 cshu webkit-unassigned ap commit-queue laszlo.gombos mitz oldest_to_newest 145821 0 cshu 2009-09-09 10:28:11 -0700 Loading a large text file on Symbian platform is slow at parsing stage. One improvement can be done is to limit the text scanning range in function Text::createWithLengthLimit(...) in Text.cpp. 145827 1 39278 cshu 2009-09-09 10:34:17 -0700 Created attachment 39278 fix patch 146011 2 39278 ariya.hidayat 2009-09-09 16:55:03 -0700 Comment on attachment 39278 fix patch > + Optimize the code so only the text from start to end is scaned. > + https://bugs.webkit.org/show_bug.cgi?id=29092 This text is too brief to provide a context of what kind of optimization is done by the commit. Can you also confirm that no test is broken by the change? Also, can you provide a comparison of performance before and after the change? r- until these issues are addressed. 147084 3 39550 cshu 2009-09-14 10:02:11 -0700 Created attachment 39550 fix patch for the bug Found issues in previous patch during regression test. Regression test went through clean with new patch. 147509 4 39550 ariya.hidayat 2009-09-16 06:08:32 -0700 Comment on attachment 39550 fix patch for the bug > + Optimize the code so only the text from start to end is scaned. Typo: scanned. > + On a platform with webkit+Qt+Symbian, the parsing time for a 600K text > + file improved 90% and overall loading time improved 20%. Could you use less ambiguous text? Improved by 90% means what? Suggested: improved from 100 ms to 75 ms (1.33x faster). 147516 5 39646 cshu 2009-09-16 06:22:37 -0700 Created attachment 39646 patch with modified description 147532 6 39646 mitz 2009-09-16 07:42:00 -0700 Comment on attachment 39646 patch with modified description > Index: WebCore/ChangeLog > =================================================================== > --- WebCore/ChangeLog (revision 48354) > +++ WebCore/ChangeLog (working copy) > @@ -1,3 +1,19 @@ > +2009-09-14 Shu Chang <Chang.Shu@nokia.com> > + > + Reviewed by NOBODY (OOPS!). > + > + Need a short description and bug URL (OOPS!) > + > + Optimize the code so only the text from start to end is scaned. > + https://bugs.webkit.org/show_bug.cgi?id=29092 > + > + On a platform with webkit+Qt+Symbian, the parsing time for a 600K text > + file improved from 400ms to 40ms (10x faster). > + Ran WebKitTools/Scripts/run-webkit-tests, and no new problem was found. > + > + * dom/Text.cpp: > + (WebCore::Text::createWithLengthLimit): > + > 2009-09-14 Yael Aharon <yael.aharon@nokia.com> > > Reviewed by Tor Arne Vestbø. > Index: WebCore/dom/Text.cpp > =================================================================== > --- WebCore/dom/Text.cpp (revision 48354) > +++ WebCore/dom/Text.cpp (working copy) > @@ -315,10 +315,12 @@ PassRefPtr<Text> Text::createWithLengthL > unsigned end = start + min(charsLeft, maxChars); > > // Check we are not on an unbreakable boundary. > - TextBreakIterator* it = characterBreakIterator(data.characters(), dataLength); > - if (end < dataLength && !isTextBreak(it, end)) > - end = textBreakPreceding(it, end); > - > + if(end < dataLength) { There’s a space missing after “if”. > + TextBreakIterator* it = characterBreakIterator(data.characters() + start, end - start + 1); > + if (!isTextBreak(it, end - start)) Are you sure one additional character is enough context? 147534 7 cshu 2009-09-16 08:17:21 -0700 Thanks for comment #6. I would think one extra character is enough for character breaking. However, I am not 100% sure if it is true about all different languages. To make it safe, more extra characters would be good and it won't affect performance. Any number could you suggest? 147543 8 mitz 2009-09-16 09:19:15 -0700 I conjecture that supplying the entire remainder of the data to the iterator will have no effect on performance. I wonder if trimming the beginning has any significant effect. I would think that the dominant part of this patch is not instantiating the iterator and not calling it when end >= dataLength. 147550 9 cshu 2009-09-16 10:03:46 -0700 (In reply to comment #8) > I conjecture that supplying the entire remainder of the data to the iterator > will have no effect on performance. I wonder if trimming the beginning has > any significant effect. It depends on lower level implementation. On Qt, calling characterBreakIterator() is very heavy with large texts. This is the major improvement with the patch. > I would think that the dominant part of this patch is not > instantiating the iterator and not calling it when end >= dataLength. This saves time of processing the last piece of the text. However, it is not significant based on the test on a platform with Qt+Symbian. 148344 10 39278 eric 2009-09-18 13:20:01 -0700 Comment on attachment 39278 fix patch Clearing r+ on this obsolete patch. 148387 11 39646 ap 2009-09-18 14:19:25 -0700 Comment on attachment 39646 patch with modified description + Optimize the code so only the text from start to end is scaned. Typo: should be "scanned". + if(end < dataLength) { Please add a space after "if". + TextBreakIterator* it = characterBreakIterator(data.characters() + start, end - start + 1); How will this behave if a non-BMP character is coming next (one that takes two UTF-16 values)? Depending on the platform implementation of the iterator, it may not work well. Seems that this needs at least "+ 2". I think that it would work then, but I'm also not 100% sure. > // If we have maxChars of unbreakable characters the above could lead to > // an infinite loop. This comment needs to be updated, now that we rely on the code below in more cases. What exactly gave the performance boost for Qt, trimming from the beginning, or from the end? If the latter is not necessary, I suggest passing the entire remainder of the text to iterator. 148406 12 cshu 2009-09-18 15:02:28 -0700 (In reply to comment #11) Thanks for the review. Just a few comments below before next patch. > Typo: should be "scanned". > Please add a space after "if". Will fix the typo and coding style in next patch. > + TextBreakIterator* it = characterBreakIterator(data.characters() + > start, end - start + 1); > How will this behave if a non-BMP character is coming next (one that takes two > UTF-16 values)? Depending on the platform implementation of the iterator, it > may not work well. > Seems that this needs at least "+ 2". I think that it would work then, but I'm also not 100% sure. To make it safe, I can use a much larger number. All I want to avoid is a huge length like 100000 or even larger. > > // If we have maxChars of unbreakable characters the above could lead to > > // an infinite loop. > This comment needs to be updated, now that we rely on the code below in more > cases. Any suggestion on how to update this comment? I don't think my changes above changed the current over-all behavoir. However, if we want to change the behavior, such as search forward for the next break instead of return the whole buffer, my change will cause problem. And in this case, the suggestion below(using the entire remainder) is a better solution. > What exactly gave the performance boost for Qt, trimming from the beginning, or > from the end? If the latter is not necessary, I suggest passing the entire > remainder of the text to iterator. In Qt implementation, when a text is passed to function characterBreakIterator(), a corresponding flag buffer is allocated (each text char is associated with several flags). Then the text is scanned for several times and the flags are filled. For details, see WebCore/platform/text/qt/TextBreakIteratorQt.cpp in webkit and corelib/tools/qtextboundaryfinder.cpp in qt. Without the improvement, the whole text is passed to this function everytime a piece of 64k of text is chopped off. Say the text length is n*64K and the time in createWithLengthLimit() using entire text is T, then the overall time are roughly: Original code: nT My code: T Using remainder of the text: nT/2. But apparently, the last option is safe and has advantages in the future. 148409 13 mitz 2009-09-18 15:05:06 -0700 (In reply to comment #11) > Seems that this needs at least "+ 2". I think that it would work then, but I'm > also not 100% sure. Of course if you use any constant greater than 1 you need to make sure you don’t overshoot. 148732 14 ap 2009-09-21 10:33:01 -0700 > To make it safe, I can use a much larger number. I don't think that would be a good thing to do. We know whay we may need to go to 2 (and it would be great if you could make a test case for that), but arbitrarily increasing the number will just make any potential issues more difficult to reproduce and correct. > > > // If we have maxChars of unbreakable characters the above could lead to > > > // an infinite loop. > > This comment needs to be updated, now that we rely on the code below in more > > cases. > > Any suggestion on how to update this comment? I don't think my changes above > changed the current over-all behavoir. You are right, I got confused. There is no need to change this comment. > Original code: nT > My code: T > Using remainder of the text: nT/2. > But apparently, the last option is safe and has advantages in the future. It seems that for Qt, halving the time isn't really sufficient, is it? 148736 15 cshu 2009-09-21 10:45:54 -0700 (In reply to comment #14) > > To make it safe, I can use a much larger number. > I don't think that would be a good thing to do. We know whay we may need to go > to 2 (and it would be great if you could make a test case for that), but > arbitrarily increasing the number will just make any potential issues more > difficult to reproduce and correct. I will try to find out if a number larger than 2 is necesary. > > > > Any suggestion on how to update this comment? I don't think my changes above > > changed the current over-all behavoir. > You are right, I got confused. There is no need to change this comment. > > Original code: nT > > My code: T > > Using remainder of the text: nT/2. > > But apparently, the last option is safe and has advantages in the future. > It seems that for Qt, halving the time isn't really sufficient, is it? :) Would the patch be ok if I can find the right number above? 149046 16 cshu 2009-09-22 07:50:46 -0700 I did some study on text breaking code in Qt implementation, which uses harfbuzz, and had the following findings. 1. In most languages except the ones mentioned below, one character is required for making character breaking decision except for surrogate handling, where two characters are required. 2. In certain languages, namely Indic, Tibetan, Myanmar and Khmer, which are supported in harfbuzz, syllables are non-breakable. I looked at each of their implementation and found in Myanmar and Khmer, the maximum syllable length is 15 and 12, correspondingly, in theory. However, Indic and Tibetan languages are different. In reality, any syllable has a limit, but I can make up a syllable that can run forever (e.g., in Tibetan, a head consonant followed by unlimited vowels). So as a result, using the remainder of the text buffer is the best compromise of code robustness and performance. Hopefully, we can improve the Qt performance later. If all the reviewers agree, I will submit the new patch. Thanks. 149070 17 ap 2009-09-22 09:29:45 -0700 > 2. In certain languages, namely Indic, Tibetan, Myanmar and Khmer, which are > supported in harfbuzz, syllables are non-breakable. I looked at each of their > implementation and found in Myanmar and Khmer, the maximum syllable length is > 15 and 12, correspondingly, in theory. It's certainly true that there are many long unbreakable character sequences in Unicode (another example is decomposed Roman text, e.g. U+0065 U+0301 U+0302 for é̂). But are there cases where unlimited look-ahead is necessary? It certainly isn't in my example, because each accent has appropriate Unicode properties that tell us about it being composed with the previous character. > So as a result, using the remainder of the text buffer is the best compromise > of code robustness and performance. Hopefully, we can improve the Qt > performance later. If all the reviewers agree, I will submit the new patch. Anything that's correct, not too complicated, and doesn't regress performance of other ports is fine with me. 149085 18 cshu 2009-09-22 10:08:53 -0700 (In reply to comment #17) > > 2. In certain languages, namely Indic, Tibetan, Myanmar and Khmer, which are > > supported in harfbuzz, syllables are non-breakable. I looked at each of their > > implementation and found in Myanmar and Khmer, the maximum syllable length is > > 15 and 12, correspondingly, in theory. > It's certainly true that there are many long unbreakable character sequences in > Unicode (another example is decomposed Roman text, e.g. U+0065 U+0301 U+0302 > for é̂). But are there cases where unlimited look-ahead is necessary? It > certainly isn't in my example, because each accent has appropriate Unicode > properties that tell us about it being composed with the previous character. By looking at the code itself (harfbuzz_tibetan.c), it does not guarantee a syllable has a limited boundary. However, I don't think there is any unlimited syllable in the real life either. > > So as a result, using the remainder of the text buffer is the best compromise > > of code robustness and performance. Hopefully, we can improve the Qt > > performance later. If all the reviewers agree, I will submit the new patch. > Anything that's correct, not too complicated, and doesn't regress performance > of other ports is fine with me. If we don't want to sacrifice the performance too much, is it ok to use +20? As I found out before, the longest syllable length is possibly 15. 149087 19 ap 2009-09-22 10:17:14 -0700 I still don't understand why +2 is not sufficient. 149114 20 cshu 2009-09-22 10:48:09 -0700 (In reply to comment #19) > I still don't understand why +2 is not sufficient. Let me explain. +2 is sufficient in most languages, but not in the four languages I mentioned. In these four languages, syllables are not breakable. One syllable may contain more than 2 characters. The reason they are not breakable is a syllable may present on display as one glyph. Using English letters as a faked example, "webkit" has two syllables, web and kit. In these languages, w-e-b may be drawn vertically as a whole glyph and k-i-t drawn vertically after w-e-b, horizontally (see below). In this case, +3 is required. w k e i b t This is what I learned yesterday. Hopefully, my understanding is correct. 149122 21 ap 2009-09-22 11:00:12 -0700 In the same example, will "we" form a non-breakable glyph, too? If it will, then there is no need to look at "web" to determine that there is no break between "w" and "e", even though we don't have a complete syllable to look for. 149137 22 cshu 2009-09-22 11:24:39 -0700 (In reply to comment #21) > In the same example, will "we" form a non-breakable glyph, too? If it will, > then there is no need to look at "web" to determine that there is no break > between "w" and "e", even though we don't have a complete syllable to look for. That makes a good point. We only break the text when it's breakable. I looked at the code again and didn't see any case that "we" is breakable but "web" is not. 149381 23 39993 cshu 2009-09-23 06:37:42 -0700 Created attachment 39993 new patch after review 149404 24 39993 ap 2009-09-23 08:49:02 -0700 Comment on attachment 39993 new patch after review > + Ran WebKitTools/Scripts/run-webkit-tests, and no new problem was found. This shouldn't be in ChangeLog, as it is not the kind of information that's interesting to anyone after the patch is landed. > + TextBreakIterator* it = characterBreakIterator(data.characters() + start, (end + 2 > dataLength) ? dataLength - start : end - start + 2); It would be nice to comment where "+ 2" comes from. This was a result of a long discussion, we can't assume that anyone looking at this code would guess what it is about. 149423 25 40002 cshu 2009-09-23 10:04:48 -0700 Created attachment 40002 patch with comments added 149448 26 40002 ap 2009-09-23 10:49:28 -0700 Comment on attachment 40002 patch with comments added r=me 150269 27 40002 eric 2009-09-26 01:30:27 -0700 Comment on attachment 40002 patch with comments added As far as I can tell Shu Chang is not a committer, setting cq+ so that this gets auto-committed for him/her. 150299 28 40002 commit-queue 2009-09-26 08:00:35 -0700 Comment on attachment 40002 patch with comments added Clearing flags on attachment: 40002 Committed r48790: <http://trac.webkit.org/changeset/48790> 150300 29 commit-queue 2009-09-26 08:00:39 -0700 All reviewed patches have been landed. Closing bug. 39278 2009-09-09 10:34:17 -0700 2009-09-18 13:20:01 -0700 fix patch bug29092.patch text/plain 1422 cshu SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0ODIwNykKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTMgQEAKKzIwMDktMDktMDkgIFNodSBDaGFuZyAgPENoYW5nLlNodUBub2tpYS5j b20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgT3B0 aW1pemUgdGhlIGNvZGUgc28gb25seSB0aGUgdGV4dCBmcm9tIHN0YXJ0IHRvIGVuZCBpcyBzY2Fu ZWQuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yOTA5 MgorCisgICAgICAgICogZG9tL1RleHQuY3BwOgorICAgICAgICAoV2ViQ29yZTo6VGV4dDo6Y3Jl YXRlV2l0aExlbmd0aExpbWl0KToKKwogMjAwOS0wOS0wOCAgUGF0IEJyYWRsZXkgIDx2aW5jZW50 LmJyYWRsZXlAbm9raWEuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IEFyaXlhIEhpZGF5YXQu CkluZGV4OiBXZWJDb3JlL2RvbS9UZXh0LmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2RvbS9U ZXh0LmNwcAkocmV2aXNpb24gNDgyMDUpCisrKyBXZWJDb3JlL2RvbS9UZXh0LmNwcAkod29ya2lu ZyBjb3B5KQpAQCAtMzE1LDkgKzMxNSw5IEBAIFBhc3NSZWZQdHI8VGV4dD4gVGV4dDo6Y3JlYXRl V2l0aExlbmd0aEwKICAgICB1bnNpZ25lZCBlbmQgPSBzdGFydCArIG1pbihjaGFyc0xlZnQsIG1h eENoYXJzKTsKICAgICAKICAgICAvLyBDaGVjayB3ZSBhcmUgbm90IG9uIGFuIHVuYnJlYWthYmxl IGJvdW5kYXJ5LgotICAgIFRleHRCcmVha0l0ZXJhdG9yKiBpdCA9IGNoYXJhY3RlckJyZWFrSXRl cmF0b3IoZGF0YS5jaGFyYWN0ZXJzKCksIGRhdGFMZW5ndGgpOwotICAgIGlmIChlbmQgPCBkYXRh TGVuZ3RoICYmICFpc1RleHRCcmVhayhpdCwgZW5kKSkKLSAgICAgICAgZW5kID0gdGV4dEJyZWFr UHJlY2VkaW5nKGl0LCBlbmQpOworICAgIFRleHRCcmVha0l0ZXJhdG9yKiBpdCA9IGNoYXJhY3Rl ckJyZWFrSXRlcmF0b3IoZGF0YS5jaGFyYWN0ZXJzKCkgKyBzdGFydCwgZW5kIC0gc3RhcnQpOwor ICAgIGlmIChlbmQgPCBkYXRhTGVuZ3RoICYmICFpc1RleHRCcmVhayhpdCwgZW5kIC0gc3RhcnQp KQorICAgICAgICBlbmQgPSB0ZXh0QnJlYWtQcmVjZWRpbmcoaXQsIGVuZCAtIHN0YXJ0KTsKICAg ICAgICAgCiAgICAgLy8gSWYgd2UgaGF2ZSBtYXhDaGFycyBvZiB1bmJyZWFrYWJsZSBjaGFyYWN0 ZXJzIHRoZSBhYm92ZSBjb3VsZCBsZWFkIHRvCiAgICAgLy8gYW4gaW5maW5pdGUgbG9vcC4K 39550 2009-09-14 10:02:11 -0700 2009-09-16 06:22:37 -0700 fix patch for the bug bug29092_2.patch text/plain 1836 cshu SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0ODM1NCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTkgQEAKKzIwMDktMDktMTQgIFNodSBDaGFuZyAgPENoYW5nLlNodUBub2tpYS5j b20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgTmVl ZCBhIHNob3J0IGRlc2NyaXB0aW9uIGFuZCBidWcgVVJMIChPT1BTISkKKworICAgICAgICBPcHRp bWl6ZSB0aGUgY29kZSBzbyBvbmx5IHRoZSB0ZXh0IGZyb20gc3RhcnQgdG8gZW5kIGlzIHNjYW5l ZC4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTI5MDky CisKKyAgICAgICAgT24gYSBwbGF0Zm9ybSB3aXRoIHdlYmtpdCtRdCtTeW1iaWFuLCB0aGUgcGFy c2luZyB0aW1lIGZvciBhIDYwMEsgdGV4dAorICAgICAgICBmaWxlIGltcHJvdmVkIDkwJSBhbmQg b3ZlcmFsbCBsb2FkaW5nIHRpbWUgaW1wcm92ZWQgMjAlLgorICAgICAgICBSYW4gV2ViS2l0VG9v bHMvU2NyaXB0cy9ydW4td2Via2l0LXRlc3RzLCBhbmQgbm8gbmV3IHByb2JsZW0gd2FzIGZvdW5k LgorCisgICAgICAgICogZG9tL1RleHQuY3BwOgorICAgICAgICAoV2ViQ29yZTo6VGV4dDo6Y3Jl YXRlV2l0aExlbmd0aExpbWl0KToKKwogMjAwOS0wOS0xNCAgWWFlbCBBaGFyb24gIDx5YWVsLmFo YXJvbkBub2tpYS5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgVG9yIEFybmUgVmVzdGLDuC4K SW5kZXg6IFdlYkNvcmUvZG9tL1RleHQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvZG9tL1Rl eHQuY3BwCShyZXZpc2lvbiA0ODM1NCkKKysrIFdlYkNvcmUvZG9tL1RleHQuY3BwCSh3b3JraW5n IGNvcHkpCkBAIC0zMTUsMTAgKzMxNSwxMiBAQCBQYXNzUmVmUHRyPFRleHQ+IFRleHQ6OmNyZWF0 ZVdpdGhMZW5ndGhMCiAgICAgdW5zaWduZWQgZW5kID0gc3RhcnQgKyBtaW4oY2hhcnNMZWZ0LCBt YXhDaGFycyk7CiAgICAgCiAgICAgLy8gQ2hlY2sgd2UgYXJlIG5vdCBvbiBhbiB1bmJyZWFrYWJs ZSBib3VuZGFyeS4KLSAgICBUZXh0QnJlYWtJdGVyYXRvciogaXQgPSBjaGFyYWN0ZXJCcmVha0l0 ZXJhdG9yKGRhdGEuY2hhcmFjdGVycygpLCBkYXRhTGVuZ3RoKTsKLSAgICBpZiAoZW5kIDwgZGF0 YUxlbmd0aCAmJiAhaXNUZXh0QnJlYWsoaXQsIGVuZCkpCi0gICAgICAgIGVuZCA9IHRleHRCcmVh a1ByZWNlZGluZyhpdCwgZW5kKTsKLSAgICAgICAgCisgICAgaWYoZW5kIDwgZGF0YUxlbmd0aCkg eworICAgICAgICBUZXh0QnJlYWtJdGVyYXRvciogaXQgPSBjaGFyYWN0ZXJCcmVha0l0ZXJhdG9y KGRhdGEuY2hhcmFjdGVycygpICsgc3RhcnQsIGVuZCAtIHN0YXJ0ICsgMSk7CisgICAgICAgIGlm ICghaXNUZXh0QnJlYWsoaXQsIGVuZCAtIHN0YXJ0KSkKKyAgICAgICAgICAgIGVuZCA9IHRleHRC cmVha1ByZWNlZGluZyhpdCwgZW5kIC0gc3RhcnQpICsgc3RhcnQ7CisgICAgfQorICAgIAogICAg IC8vIElmIHdlIGhhdmUgbWF4Q2hhcnMgb2YgdW5icmVha2FibGUgY2hhcmFjdGVycyB0aGUgYWJv dmUgY291bGQgbGVhZCB0bwogICAgIC8vIGFuIGluZmluaXRlIGxvb3AuCiAgICAgLy8gRklYTUU6 IEl0IHdvdWxkIGJlIGJldHRlciB0byBqdXN0IGhhdmUgdGhlIG9sZCB2YWx1ZSBvZiBlbmQgYmVm b3JlIGNhbGxpbmcK 39646 2009-09-16 06:22:37 -0700 2009-09-23 06:37:42 -0700 patch with modified description bug29092_3.patch text/plain 1826 cshu SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0ODM1NCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTkgQEAKKzIwMDktMDktMTQgIFNodSBDaGFuZyAgPENoYW5nLlNodUBub2tpYS5j b20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgTmVl ZCBhIHNob3J0IGRlc2NyaXB0aW9uIGFuZCBidWcgVVJMIChPT1BTISkKKworICAgICAgICBPcHRp bWl6ZSB0aGUgY29kZSBzbyBvbmx5IHRoZSB0ZXh0IGZyb20gc3RhcnQgdG8gZW5kIGlzIHNjYW5l ZC4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTI5MDky CisKKyAgICAgICAgT24gYSBwbGF0Zm9ybSB3aXRoIHdlYmtpdCtRdCtTeW1iaWFuLCB0aGUgcGFy c2luZyB0aW1lIGZvciBhIDYwMEsgdGV4dAorICAgICAgICBmaWxlIGltcHJvdmVkIGZyb20gNDAw bXMgdG8gNDBtcyAoMTB4IGZhc3RlcikuCisgICAgICAgIFJhbiBXZWJLaXRUb29scy9TY3JpcHRz L3J1bi13ZWJraXQtdGVzdHMsIGFuZCBubyBuZXcgcHJvYmxlbSB3YXMgZm91bmQuCisKKyAgICAg ICAgKiBkb20vVGV4dC5jcHA6CisgICAgICAgIChXZWJDb3JlOjpUZXh0OjpjcmVhdGVXaXRoTGVu Z3RoTGltaXQpOgorCiAyMDA5LTA5LTE0ICBZYWVsIEFoYXJvbiAgPHlhZWwuYWhhcm9uQG5va2lh LmNvbT4KIAogICAgICAgICBSZXZpZXdlZCBieSBUb3IgQXJuZSBWZXN0YsO4LgpJbmRleDogV2Vi Q29yZS9kb20vVGV4dC5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9kb20vVGV4dC5jcHAJKHJl dmlzaW9uIDQ4MzU0KQorKysgV2ViQ29yZS9kb20vVGV4dC5jcHAJKHdvcmtpbmcgY29weSkKQEAg LTMxNSwxMCArMzE1LDEyIEBAIFBhc3NSZWZQdHI8VGV4dD4gVGV4dDo6Y3JlYXRlV2l0aExlbmd0 aEwKICAgICB1bnNpZ25lZCBlbmQgPSBzdGFydCArIG1pbihjaGFyc0xlZnQsIG1heENoYXJzKTsK ICAgICAKICAgICAvLyBDaGVjayB3ZSBhcmUgbm90IG9uIGFuIHVuYnJlYWthYmxlIGJvdW5kYXJ5 LgotICAgIFRleHRCcmVha0l0ZXJhdG9yKiBpdCA9IGNoYXJhY3RlckJyZWFrSXRlcmF0b3IoZGF0 YS5jaGFyYWN0ZXJzKCksIGRhdGFMZW5ndGgpOwotICAgIGlmIChlbmQgPCBkYXRhTGVuZ3RoICYm ICFpc1RleHRCcmVhayhpdCwgZW5kKSkKLSAgICAgICAgZW5kID0gdGV4dEJyZWFrUHJlY2VkaW5n KGl0LCBlbmQpOwotICAgICAgICAKKyAgICBpZihlbmQgPCBkYXRhTGVuZ3RoKSB7CisgICAgICAg IFRleHRCcmVha0l0ZXJhdG9yKiBpdCA9IGNoYXJhY3RlckJyZWFrSXRlcmF0b3IoZGF0YS5jaGFy YWN0ZXJzKCkgKyBzdGFydCwgZW5kIC0gc3RhcnQgKyAxKTsKKyAgICAgICAgaWYgKCFpc1RleHRC cmVhayhpdCwgZW5kIC0gc3RhcnQpKQorICAgICAgICAgICAgZW5kID0gdGV4dEJyZWFrUHJlY2Vk aW5nKGl0LCBlbmQgLSBzdGFydCkgKyBzdGFydDsKKyAgICB9CisgICAgCiAgICAgLy8gSWYgd2Ug aGF2ZSBtYXhDaGFycyBvZiB1bmJyZWFrYWJsZSBjaGFyYWN0ZXJzIHRoZSBhYm92ZSBjb3VsZCBs ZWFkIHRvCiAgICAgLy8gYW4gaW5maW5pdGUgbG9vcC4KICAgICAvLyBGSVhNRTogSXQgd291bGQg YmUgYmV0dGVyIHRvIGp1c3QgaGF2ZSB0aGUgb2xkIHZhbHVlIG9mIGVuZCBiZWZvcmUgY2FsbGlu Zwo= 39993 2009-09-23 06:37:42 -0700 2009-09-23 10:04:48 -0700 new patch after review bug29092_4.patch text/plain 1813 cshu SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0ODY3MykKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTcgQEAKKzIwMDktMDktMjMgIFNodSBDaGFuZyAgPENoYW5nLlNodUBub2tpYS5j b20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgT3B0 aW1pemUgdGhlIGNvZGUgc28gb25seSB0aGUgdGV4dCBmcm9tIHN0YXJ0IHRvIGVuZCBpcyBzY2Fu bmVkLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Mjkw OTIKKworICAgICAgICBPbiBhIHBsYXRmb3JtIHdpdGggd2Via2l0K1F0K1N5bWJpYW4sIHRoZSBw YXJzaW5nIHRpbWUgZm9yIGEgNjAwSyB0ZXh0CisgICAgICAgIGZpbGUgaW1wcm92ZWQgZnJvbSA0 MDBtcyB0byA0MG1zICgxMHggZmFzdGVyKS4KKyAgICAgICAgUmFuIFdlYktpdFRvb2xzL1Njcmlw dHMvcnVuLXdlYmtpdC10ZXN0cywgYW5kIG5vIG5ldyBwcm9ibGVtIHdhcyBmb3VuZC4KKworICAg ICAgICAqIGRvbS9UZXh0LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlRleHQ6OmNyZWF0ZVdpdGhM ZW5ndGhMaW1pdCk6CisKIDIwMDktMDktMjMgIEd1c3Rhdm8gTm9yb25oYSBTaWx2YSAgPGduc0Bn bm9tZS5vcmc+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgWGFuIExvcGV6LgpJbmRleDogV2ViQ29y ZS9kb20vVGV4dC5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9kb20vVGV4dC5jcHAJKHJldmlz aW9uIDQ4NjQyKQorKysgV2ViQ29yZS9kb20vVGV4dC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTMx NSwxMCArMzE1LDEyIEBAIFBhc3NSZWZQdHI8VGV4dD4gVGV4dDo6Y3JlYXRlV2l0aExlbmd0aEwK ICAgICB1bnNpZ25lZCBlbmQgPSBzdGFydCArIG1pbihjaGFyc0xlZnQsIG1heENoYXJzKTsKICAg ICAKICAgICAvLyBDaGVjayB3ZSBhcmUgbm90IG9uIGFuIHVuYnJlYWthYmxlIGJvdW5kYXJ5Lgot ICAgIFRleHRCcmVha0l0ZXJhdG9yKiBpdCA9IGNoYXJhY3RlckJyZWFrSXRlcmF0b3IoZGF0YS5j aGFyYWN0ZXJzKCksIGRhdGFMZW5ndGgpOwotICAgIGlmIChlbmQgPCBkYXRhTGVuZ3RoICYmICFp c1RleHRCcmVhayhpdCwgZW5kKSkKLSAgICAgICAgZW5kID0gdGV4dEJyZWFrUHJlY2VkaW5nKGl0 LCBlbmQpOwotICAgICAgICAKKyAgICBpZiAoZW5kIDwgZGF0YUxlbmd0aCkgeworICAgICAgICBU ZXh0QnJlYWtJdGVyYXRvciogaXQgPSBjaGFyYWN0ZXJCcmVha0l0ZXJhdG9yKGRhdGEuY2hhcmFj dGVycygpICsgc3RhcnQsIChlbmQgKyAyID4gZGF0YUxlbmd0aCkgPyBkYXRhTGVuZ3RoIC0gc3Rh cnQgOiBlbmQgLSBzdGFydCArIDIpOworICAgICAgICBpZiAoIWlzVGV4dEJyZWFrKGl0LCBlbmQg LSBzdGFydCkpCisgICAgICAgICAgICBlbmQgPSB0ZXh0QnJlYWtQcmVjZWRpbmcoaXQsIGVuZCAt IHN0YXJ0KSArIHN0YXJ0OworICAgIH0KKyAgICAKICAgICAvLyBJZiB3ZSBoYXZlIG1heENoYXJz IG9mIHVuYnJlYWthYmxlIGNoYXJhY3RlcnMgdGhlIGFib3ZlIGNvdWxkIGxlYWQgdG8KICAgICAv LyBhbiBpbmZpbml0ZSBsb29wLgogICAgIC8vIEZJWE1FOiBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8g anVzdCBoYXZlIHRoZSBvbGQgdmFsdWUgb2YgZW5kIGJlZm9yZSBjYWxsaW5nCg== 40002 2009-09-23 10:04:48 -0700 2009-09-26 08:00:35 -0700 patch with comments added bug29092_5.patch text/plain 1980 cshu SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0ODY3OSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTYgQEAKKzIwMDktMDktMjMgIFNodSBDaGFuZyAgPENoYW5nLlNodUBub2tpYS5j b20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgT3B0 aW1pemUgdGhlIGNvZGUgc28gb25seSB0aGUgdGV4dCBmcm9tIHN0YXJ0IHRvIGVuZCBpcyBzY2Fu bmVkLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Mjkw OTIKKworICAgICAgICBPbiBhIHBsYXRmb3JtIHdpdGggd2Via2l0K1F0K1N5bWJpYW4sIHRoZSBw YXJzaW5nIHRpbWUgZm9yIGEgNjAwSyB0ZXh0CisgICAgICAgIGZpbGUgaW1wcm92ZWQgZnJvbSA0 MDBtcyB0byA0MG1zICgxMHggZmFzdGVyKS4KKworICAgICAgICAqIGRvbS9UZXh0LmNwcDoKKyAg ICAgICAgKFdlYkNvcmU6OlRleHQ6OmNyZWF0ZVdpdGhMZW5ndGhMaW1pdCk6CisKIDIwMDktMDkt MjIgIERhdmUgSHlhdHQgIDxoeWF0dEBhcHBsZS5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkg Sm9obiBTdWxsaXZhbi4KSW5kZXg6IFdlYkNvcmUvZG9tL1RleHQuY3BwCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IFdlYkNvcmUvZG9tL1RleHQuY3BwCShyZXZpc2lvbiA0ODY0MikKKysrIFdlYkNvcmUvZG9tL1Rl eHQuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0zMTUsMTAgKzMxNSwxNSBAQCBQYXNzUmVmUHRyPFRl eHQ+IFRleHQ6OmNyZWF0ZVdpdGhMZW5ndGhMCiAgICAgdW5zaWduZWQgZW5kID0gc3RhcnQgKyBt aW4oY2hhcnNMZWZ0LCBtYXhDaGFycyk7CiAgICAgCiAgICAgLy8gQ2hlY2sgd2UgYXJlIG5vdCBv biBhbiB1bmJyZWFrYWJsZSBib3VuZGFyeS4KLSAgICBUZXh0QnJlYWtJdGVyYXRvciogaXQgPSBj aGFyYWN0ZXJCcmVha0l0ZXJhdG9yKGRhdGEuY2hhcmFjdGVycygpLCBkYXRhTGVuZ3RoKTsKLSAg ICBpZiAoZW5kIDwgZGF0YUxlbmd0aCAmJiAhaXNUZXh0QnJlYWsoaXQsIGVuZCkpCi0gICAgICAg IGVuZCA9IHRleHRCcmVha1ByZWNlZGluZyhpdCwgZW5kKTsKLSAgICAgICAgCisgICAgLy8gU29t ZSB0ZXh0IGJyZWFrIGl0ZXJhdG9yIGltcGxlbWVudGF0aW9ucyB3b3JrIGJlc3QgaWYgdGhlIHBh c3NlZCBidWZmZXIgaXMgYXMgc21hbGwgYXMgcG9zc2libGUsIAorICAgIC8vIHNlZSA8aHR0cHM6 Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTI5MDkyPi4gCisgICAgLy8gV2UgbmVl ZCBhdCBsZWFzdCB0d28gY2hhcmFjdGVycyBsb29rLWFoZWFkIHRvIGFjY291bnQgZm9yIFVURi0x NiBzdXJyb2dhdGVzLgorICAgIGlmIChlbmQgPCBkYXRhTGVuZ3RoKSB7CisgICAgICAgIFRleHRC cmVha0l0ZXJhdG9yKiBpdCA9IGNoYXJhY3RlckJyZWFrSXRlcmF0b3IoZGF0YS5jaGFyYWN0ZXJz KCkgKyBzdGFydCwgKGVuZCArIDIgPiBkYXRhTGVuZ3RoKSA/IGRhdGFMZW5ndGggLSBzdGFydCA6 IGVuZCAtIHN0YXJ0ICsgMik7CisgICAgICAgIGlmICghaXNUZXh0QnJlYWsoaXQsIGVuZCAtIHN0 YXJ0KSkKKyAgICAgICAgICAgIGVuZCA9IHRleHRCcmVha1ByZWNlZGluZyhpdCwgZW5kIC0gc3Rh cnQpICsgc3RhcnQ7CisgICAgfQorICAgIAogICAgIC8vIElmIHdlIGhhdmUgbWF4Q2hhcnMgb2Yg dW5icmVha2FibGUgY2hhcmFjdGVycyB0aGUgYWJvdmUgY291bGQgbGVhZCB0bwogICAgIC8vIGFu IGluZmluaXRlIGxvb3AuCiAgICAgLy8gRklYTUU6IEl0IHdvdWxkIGJlIGJldHRlciB0byBqdXN0 IGhhdmUgdGhlIG9sZCB2YWx1ZSBvZiBlbmQgYmVmb3JlIGNhbGxpbmcK