Re: [webkit-dev] programmatic text selection
On 5/26/06, Giacomo Luca Maioli <luca@tricheco.net> wrote:
But Safari throws an error while processing the last method (the one which actually highlight text), so you should try:
window.getSelection().setBaseAndExtent(selDiv, 0, selDiv, 1);
So you'll only need to play around with this (strange and mostly unknown) method.
I'm afraid Safari doesn't appear to support setBaseAndExtent() method on a selection, either.
I just tested the code on both Firefox and Safari. You can find a working example here: http://www.tricheco.net/selection.html I'm using Safari Version 2.0.3 (417.9.3) and Firefox 1.5.0.3 on Mac and Windows.
Finally found some benchmarks form what I can tell Firefox is significantly faster on scripts then Safari http://www.howtocreate.co.uk/browserSpeed.html#testresults It does look like the khtml engine itself is quite fast so the combination of SpiderMonkey with WebCore should make a very fast browser. Again please prove that KJS is faster then SpiderMonkey everything I finds shows not only is this not true but it is significantly slower. I see no reason that the proposal to integrate SpiderMonkey slim it down and do a little performance tunning is not valid and resonable approach. I see no reason to start from scratch on a new interpeter. Finally I think this benchmark should be run agianst webkit/IE/Firefox and the results should be on the website it would be helpful. It took me a while to find a page with a reasonable set of results. Mike On 5/26/06, Giacomo Luca Maioli <luca@tricheco.net> wrote:
On 5/26/06, Giacomo Luca Maioli <luca@tricheco.net> wrote:
But Safari throws an error while processing the last method (the one which actually highlight text), so you should try:
window.getSelection().setBaseAndExtent(selDiv, 0, selDiv, 1);
So you'll only need to play around with this (strange and mostly unknown) method.
I'm afraid Safari doesn't appear to support setBaseAndExtent() method on a selection, either.
I just tested the code on both Firefox and Safari. You can find a working example here:
http://www.tricheco.net/selection.html
I'm using Safari Version 2.0.3 (417.9.3) and Firefox 1.5.0.3 on Mac and Windows.
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
I think Maciej's earlier message about this topic did an excellent job of explaining the different issues here. I just wanted to add that as far as I can tell, the howtocreate link below seems to show that Safari 2.0 is faster than Firefox in every listed category other than "Multiple images", in which Firefox 1.5 is a little faster than Safari 2.0. For "Script speed" it gives: Firefox 1.0 (krmathis) 53 Firefox 1.0 72 Firefox 1.5 40 Safari 2.0 27 where lower numbers are faster. So I'm not sure why you claim that this page shows Firefox as significantly faster on scripts than Safari. John On May 26, 2006, at 3:08 PM, Mike Emmel wrote:
Finally found some benchmarks form what I can tell Firefox is significantly faster on scripts then Safari
http://www.howtocreate.co.uk/browserSpeed.html#testresults
It does look like the khtml engine itself is quite fast so the combination of SpiderMonkey with WebCore should make a very fast browser.
Again please prove that KJS is faster then SpiderMonkey everything I finds shows not only is this not true but it is significantly slower. I see no reason that the proposal to integrate SpiderMonkey slim it down and do a little performance tunning is not valid and resonable approach. I see no reason to start from scratch on a new interpeter.
Finally I think this benchmark should be run agianst webkit/IE/Firefox and the results should be on the website it would be helpful. It took me a while to find a page with a reasonable set of results.
Mike
I was looking at the Linux KDE numbers KJS where it is a lot slower. I actually did not see the last number till later after the email was sent. I was looking at the treecode branch. Its impressive I did not believe it was possible to get a AST to perform on par with bytecode you learn something every day historically there 5-10 times slower. Its seems I was wrong and gave the link to prove it :) In this case Firefox1.5 on Linux with a score of 24 should be compared to Safari 2.0 with a 22 and indeed the performance is on par. Note that Opera is a 10. Now with a bytecode interpeter Webkit should be down with Opera maybe even better. I do agree now that the latest numbers look good. With that said my fundamental concern about the AST approach is it does not scale well to thousands of lines of javascript thats starting to show up in current AJAX apps but if apples getting these numbers with a AST I'm intrested to see the results with a optimized bytecode implementation. Mike On 5/26/06, John Sullivan <sullivan@apple.com> wrote:
I think Maciej's earlier message about this topic did an excellent job of explaining the different issues here. I just wanted to add that as far as I can tell, the howtocreate link below seems to show that Safari 2.0 is faster than Firefox in every listed category other than "Multiple images", in which Firefox 1.5 is a little faster than Safari 2.0. For "Script speed" it gives:
Firefox 1.0 (krmathis) 53 Firefox 1.0 72 Firefox 1.5 40 Safari 2.0 27
where lower numbers are faster.
So I'm not sure why you claim that this page shows Firefox as significantly faster on scripts than Safari.
John
On May 26, 2006, at 3:08 PM, Mike Emmel wrote:
Finally found some benchmarks form what I can tell Firefox is significantly faster on scripts then Safari
http://www.howtocreate.co.uk/browserSpeed.html#testresults
It does look like the khtml engine itself is quite fast so the combination of SpiderMonkey with WebCore should make a very fast browser.
Again please prove that KJS is faster then SpiderMonkey everything I finds shows not only is this not true but it is significantly slower. I see no reason that the proposal to integrate SpiderMonkey slim it down and do a little performance tunning is not valid and resonable approach. I see no reason to start from scratch on a new interpeter.
Finally I think this benchmark should be run agianst webkit/IE/Firefox and the results should be on the website it would be helpful. It took me a while to find a page with a reasonable set of results.
Mike
On May 26, 2006, at 5:35 PM, Mike Emmel wrote:
I was looking at the Linux KDE numbers KJS where it is a lot slower. I actually did not see the last number till later after the email was sent. I was looking at the treecode branch.
Its impressive I did not believe it was possible to get a AST to perform on par with bytecode you learn something every day historically there 5-10 times slower.
Its seems I was wrong and gave the link to prove it :)
In this case Firefox1.5 on Linux with a score of 24 should be compared to Safari 2.0 with a 22 and indeed the performance is on par. Note that Opera is a 10. Now with a bytecode interpeter Webkit should be down with Opera maybe even better.
In those results, Firefox on Linux and Safari on a PPC Mac aren't running on comparable hardware, so no, I don't think the performance is on par. I'll also note that current TOT WebKit is likely to be significantly faster than Safari 2.0. Then again, Firefox trunk nightly builds could be faster too, for all I know. Feel free to rerun the benchmark yourself on newer versions, perhaps on an Intel mac which should allow even cross-OS comparisons on comparable hardware. Regards, Maciej
On 5/27/06, Maciej Stachowiak <mjs@apple.com> wrote:
On May 26, 2006, at 5:35 PM, Mike Emmel wrote:
I was looking at the Linux KDE numbers KJS where it is a lot slower. I actually did not see the last number till later after the email was sent. I was looking at the treecode branch.
Its impressive I did not believe it was possible to get a AST to perform on par with bytecode you learn something every day historically there 5-10 times slower.
Its seems I was wrong and gave the link to prove it :)
In this case Firefox1.5 on Linux with a score of 24 should be compared to Safari 2.0 with a 22 and indeed the performance is on par. Note that Opera is a 10. Now with a bytecode interpeter Webkit should be down with Opera maybe even better.
In those results, Firefox on Linux and Safari on a PPC Mac aren't running on comparable hardware, so no, I don't think the performance is on par. I'll also note that current TOT WebKit is likely to be significantly faster than Safari 2.0. Then again, Firefox trunk nightly builds could be faster too, for all I know. Feel free to rerun the benchmark yourself on newer versions, perhaps on an Intel mac which should allow even cross-OS comparisons on comparable hardware.
I think I've been soundly refuted for my statements I think a better approach would be to keep my mouth shut. I do find it intresting that a AST based interperter is showing performance on par with bytecode solutions. All I can hope for now is enough posts to the group to bury this thread in the archives. Mike
Regards, Maciej
On May 26, 2006, at 2:08 PM, Mike Emmel wrote:
Finally found some benchmarks form what I can tell Firefox is significantly faster on scripts then Safari
On the test you linked I see Safari 2.0 getting 27 seconds compared to Firefox 1.5's 40 seconds on the script speed test. That's even just Safari 2.0.... TOT is much faster than 2.0. Your definition of "fast" doesn't seem to match up with mine. :) Which specific JavaScript test in that chart shows Firefox to be faster than Safari?
Again please prove that KJS is faster then SpiderMonkey everything I finds shows not only is this not true but it is significantly slower.
Everything you find where? You've linked to a benchmark that shows JavaScriptCore is faster.... not really helping your case any... :)
I see no reason that the proposal to integrate SpiderMonkey slim it down and do a little performance tunning is not valid and resonable approach. I see no reason to start from scratch on a new interpeter.
Who is starting from scratch? Our interpreter has been around for years.
Finally I think this benchmark should be run agianst webkit/IE/Firefox and the results should be on the website it would be helpful. It took me a while to find a page with a reasonable set of results.
Results that you seem to have misread.... maybe you should keep digging. Cheers, dave (hyatt@apple.com)
Just so my reply is not lost. Yep your right and as I said in my other post I proved myself wrong :) Impressive. On 5/26/06, David Hyatt <hyatt@apple.com> wrote:
On May 26, 2006, at 2:08 PM, Mike Emmel wrote:
Finally found some benchmarks form what I can tell Firefox is significantly faster on scripts then Safari
On the test you linked I see Safari 2.0 getting 27 seconds compared to Firefox 1.5's 40 seconds on the script speed test. That's even just Safari 2.0.... TOT is much faster than 2.0. Your definition of "fast" doesn't seem to match up with mine. :)
Which specific JavaScript test in that chart shows Firefox to be faster than Safari?
Again please prove that KJS is faster then SpiderMonkey everything I finds shows not only is this not true but it is significantly slower.
Everything you find where? You've linked to a benchmark that shows JavaScriptCore is faster.... not really helping your case any... :)
I see no reason that the proposal to integrate SpiderMonkey slim it down and do a little performance tunning is not valid and resonable approach. I see no reason to start from scratch on a new interpeter.
Who is starting from scratch? Our interpreter has been around for years.
Finally I think this benchmark should be run agianst webkit/IE/Firefox and the results should be on the website it would be helpful. It took me a while to find a page with a reasonable set of results.
Results that you seem to have misread.... maybe you should keep digging.
Cheers, dave (hyatt@apple.com)
Thanks Giacomo - I think your original example had a typo (the 1 as a last parameter), as the page you provided works great (a 0 as the last parameter). One question - how does one select a node which has no sibling? Putting the same node as both node parameters to setBaseAndExtent has no effect. --sam On 5/26/06, Giacomo Luca Maioli <luca@tricheco.net> wrote:
On 5/26/06, Giacomo Luca Maioli <luca@tricheco.net> wrote:
But Safari throws an error while processing the last method (the one which actually highlight text), so you should try:
window.getSelection().setBaseAndExtent(selDiv, 0, selDiv, 1);
So you'll only need to play around with this (strange and mostly unknown) method.
I'm afraid Safari doesn't appear to support setBaseAndExtent() method on a selection, either.
I just tested the code on both Firefox and Safari. You can find a working example here:
http://www.tricheco.net/selection.html
I'm using Safari Version 2.0.3 (417.9.3) and Firefox 1.5.0.3 on Mac and Windows.
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
Il giorno 26/mag/06, alle ore 23:12, Sam Gendler ha scritto:
Thanks Giacomo - I think your original example had a typo (the 1 as a last parameter), as the page you provided works great (a 0 as the last parameter).
One question - how does one select a node which has no sibling? Putting the same node as both node parameters to setBaseAndExtent has no effect.
--sam
Putting the same node with different offset works for me (this works in setBaseAndExtent but not with the range object in mozilla) if I use different (incremental) offset values. For example:
window.getSelection().setBaseAndExtent(selDiv, 0, selDiv, 1); // Same node, different offsets.
Gives the same result as the published example.
participants (6)
-
David Hyatt
-
Giacomo Luca Maioli
-
John Sullivan
-
Maciej Stachowiak
-
Mike Emmel
-
Sam Gendler