[webkit-dev] performance improvement techniques for JSCORE
Hi guys, Can anyone suggest performance improvement techniques for JSCORE . SFX is already implemeted... -- Nagarjuna ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tech Talk on WebKit
In the "Rendering in WebKit" talk it mentioned that the RIM Sidekick runs WebKit, Sidekick isn't made by RIM, but by Microsoft/Danger/T-Mobile and last I checked they have a home grown browser written in Java. -Benjamin Meyer On Jan 4, 2010, at 10:38 PM, Eric Seidel wrote: > Thanks Jeremy. > > I did my best to tell the whole truth and nothing but the truth, but > if there are factual errors in my talk, I'd love to know about them. > > -eric > > On Mon, Jan 4, 2010 at 6:25 PM, Jeremy Orlow wrote: >> (Oops, I meant to post this before the holidays but completely forgot. >> Better late than never I suppose?) >> A couple weeks ago, Eric Seidel gave a tech talk to a live studio audience >> of Googlers on the guts of webkit. Although there are a few bits that only >> apply to Chromium, the vast majority of it is simply about WebKit, and thus >> I thought it might be of interest to others here. The talk operates mostly >> at a 10,000 foot view and looks at how loading occurs and then steps through >> many of the various trees used to represent the DOM and handle rendering. >> http://www.youtube.com/watch?v=RVnARGhhs9w >> Btw, if anyone else is ever giving a talk on WebKit in the bay area and >> would like it recorded and put on YouTube, let me know. I'd be more than >> happy to make it happen. :-) >> J > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tech Talk on WebKit
Well, if there's enough errors, maybe it'll guilt Hyatt into giving a talk. O wait...was that out loud? :-) J On Mon, Jan 4, 2010 at 7:38 PM, Eric Seidel wrote: > Thanks Jeremy. > > I did my best to tell the whole truth and nothing but the truth, but > if there are factual errors in my talk, I'd love to know about them. > > -eric > > On Mon, Jan 4, 2010 at 6:25 PM, Jeremy Orlow wrote: > > (Oops, I meant to post this before the holidays but completely forgot. > > Better late than never I suppose?) > > A couple weeks ago, Eric Seidel gave a tech talk to a live studio > audience > > of Googlers on the guts of webkit. Although there are a few bits that > only > > apply to Chromium, the vast majority of it is simply about WebKit, and > thus > > I thought it might be of interest to others here. The talk operates > mostly > > at a 10,000 foot view and looks at how loading occurs and then steps > through > > many of the various trees used to represent the DOM and handle rendering. > > http://www.youtube.com/watch?v=RVnARGhhs9w > > Btw, if anyone else is ever giving a talk on WebKit in the bay area and > > would like it recorded and put on YouTube, let me know. I'd be more than > > happy to make it happen. :-) > > J > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tech Talk on WebKit
Thanks Jeremy. I did my best to tell the whole truth and nothing but the truth, but if there are factual errors in my talk, I'd love to know about them. -eric On Mon, Jan 4, 2010 at 6:25 PM, Jeremy Orlow wrote: > (Oops, I meant to post this before the holidays but completely forgot. > Better late than never I suppose?) > A couple weeks ago, Eric Seidel gave a tech talk to a live studio audience > of Googlers on the guts of webkit. Although there are a few bits that only > apply to Chromium, the vast majority of it is simply about WebKit, and thus > I thought it might be of interest to others here. The talk operates mostly > at a 10,000 foot view and looks at how loading occurs and then steps through > many of the various trees used to represent the DOM and handle rendering. > http://www.youtube.com/watch?v=RVnARGhhs9w > Btw, if anyone else is ever giving a talk on WebKit in the bay area and > would like it recorded and put on YouTube, let me know. I'd be more than > happy to make it happen. :-) > J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Tech Talk on WebKit
(Oops, I meant to post this before the holidays but completely forgot. Better late than never I suppose?) A couple weeks ago, Eric Seidel gave a tech talk to a live studio audience of Googlers on the guts of webkit. Although there are a few bits that only apply to Chromium, the vast majority of it is simply about WebKit, and thus I thought it might be of interest to others here. The talk operates mostly at a 10,000 foot view and looks at how loading occurs and then steps through many of the various trees used to represent the DOM and handle rendering. http://www.youtube.com/watch?v=RVnARGhhs9w Btw, if anyone else is ever giving a talk on WebKit in the bay area and would like it recorded and put on YouTube, let me know. I'd be more than happy to make it happen. :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to map local file extension to the MIMEType
On Mon, January 4, 2010 at 5:19:46 PM, Fei Wang wrote: > I define my own MIMEType like application/foo with file extension .foo. It > works > fine if I serve file through web server ( inside web server configuration, I > add > application/foo foo to the mime type map). In the webkit, I modify the > MIMETypeRegistry.cpp file, add those MIMEType in. It works if I serve the > file > from webserver. > > But it does not work if I want to open the file xxx.foo locally. > > I use build-webkit script to build it in my mac. But if I want to open safari > to > open local file with .foo extension, it grey out that file. > > Does anyone know how to add customized MimeType with local file extension to > the > webkit? See: WebCore/platform/MIMETypeRegistry.cpp WebCore/platform/mac/MIMETypeRegistryMac.mm Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how to map local file extension to the MIMEType
Please help! I define my own MIMEType like application/foo with file extension .foo. It works fine if I serve file through web server ( inside web server configuration, I add application/foo foo to the mime type map). In the webkit, I modify the MIMETypeRegistry.cpp file, add those MIMEType in. It works if I serve the file from webserver. But it does not work if I want to open the file xxx.foo locally. I use build-webkit script to build it in my mac. But if I want to open safari to open local file with .foo extension, it grey out that file. Does anyone know how to add customized MimeType with local file extension to the webkit? Thanks a lot Frank ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] #endif // Foo_h
We have somtimes constructs like #endif // ENABLE(SVG) #endif // Foo_h It just helps to understand why there are two endif's and what they are good for. I think it's not a style issue not to write this comment, but it can be helpful. -Dirk Am Montag, den 04.01.2010, 15:41 -0800 schrieb Darin Adler: > On Jan 4, 2010, at 3:33 PM, Darin Fisher wrote: > > > I noticed recently that the style bot started complaining about header > > files ending with "#endif" instead of "#endif // Foo_h". I was surprised > > by this since the style guide does not require it. > > I personally see little value in this sort of comment at the end of a header > file. I’m not sure what kind of problem it’s supposed to prevent. > > -- Darin > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] #endif // Foo_h
These seemed to be common in WebKit code, so I had it in http://lists.macosforge.org/pipermail/webkit-dev/2009-September/009807.html(-- Sorry for letting this one linger for so long. It is in my queue just low on the priority list). Here's the relevant part: #if(def) statements If an #if(def) spans more than a few lines, end it like this: #endif // WhateverWasInTheIf Like with many of these style issues, I don't care either way about this issue but was simply trying to note what seemed to be commonly done, so I'm fine with not having this. dave PS I'll bump on the priority on translating that email into the style guide. (I'll try to do it this week.) On Mon, Jan 4, 2010 at 3:41 PM, Darin Adler wrote: > On Jan 4, 2010, at 3:33 PM, Darin Fisher wrote: > > > I noticed recently that the style bot started complaining about header > files ending with "#endif" instead of "#endif // Foo_h". I was surprised by > this since the style guide does not require it. > > I personally see little value in this sort of comment at the end of a > header file. I’m not sure what kind of problem it’s supposed to prevent. > >-- Darin > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] #endif // Foo_h
On Jan 4, 2010, at 3:33 PM, Darin Fisher wrote: > I noticed recently that the style bot started complaining about header files > ending with "#endif" instead of "#endif // Foo_h". I was surprised by this > since the style guide does not require it. I personally see little value in this sort of comment at the end of a header file. I’m not sure what kind of problem it’s supposed to prevent. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] #endif // Foo_h
I noticed recently that the style bot started complaining about header files ending with "#endif" instead of "#endif // Foo_h". I was surprised by this since the style guide does not require it. Should the style guide be changed to require this comment, or should the style bot be taught to ignore this issue? -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] RenderObject is-a boolean methods
I agree that line-layout logic could be split out of RenderBlock at some point. RenderSVGBlock inherits from RenderBlock in order to get line layout logic, yet it probably doesn't want to be a real RenderBlock long term. -eric On Mon, Jan 4, 2010 at 3:21 PM, Alex Milowski wrote: > On Mon, Jan 4, 2010 at 1:02 PM, Eric Seidel wrote: >> My understanding is that RenderObject::isRenderMathMLBlock() is the >> right approach, yes. Although if MathML base renderer (like >> RenderBoxModelObject or RenderSVGModelObject), then an >> isMathMLModelObject() would be even better. Then you only add one >> method to RenderObject and the rest can go on your base renderer. > > The base for all my objects is currently RenderBlock as I use the line > layout for its interior. Most of the time they are set to display as > "inline-block". > > If the line layout was more of a generic algorithm, I could reuse it > without having to inherit from RenderBlock. I suspect there are times > where I may not want RenderBlock as a parent. In other cases, I > use other render objects directly (e.g. RenderTable for mtable). > > In MathML, even simple elements like "mo" (math operator) can > have complex content. For example, a stretchable operator like > a left bracket is made from stacking left-to-right glyphs vertically. I > currently use a sequence of blocks stacked vertically to handle > this and it seems to work quite nicely. > > While I have some reservations about inheriting from RenderBlock, for > now this seems like the right thing to do. My only other option > would be somehow "duplicate" the line layout--which is something > I have no justification for right now. > > > -- > --Alex Milowski > "The excellence of grammar as a guide is proportional to the paucity of the > inflexions, i.e. to the degree of analysis effected by the language > considered." > > Bertrand Russell in a footnote of Principles of Mathematics > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] RenderObject is-a boolean methods
On Mon, Jan 4, 2010 at 1:02 PM, Eric Seidel wrote: > My understanding is that RenderObject::isRenderMathMLBlock() is the > right approach, yes. Although if MathML base renderer (like > RenderBoxModelObject or RenderSVGModelObject), then an > isMathMLModelObject() would be even better. Then you only add one > method to RenderObject and the rest can go on your base renderer. The base for all my objects is currently RenderBlock as I use the line layout for its interior. Most of the time they are set to display as "inline-block". If the line layout was more of a generic algorithm, I could reuse it without having to inherit from RenderBlock. I suspect there are times where I may not want RenderBlock as a parent. In other cases, I use other render objects directly (e.g. RenderTable for mtable). In MathML, even simple elements like "mo" (math operator) can have complex content. For example, a stretchable operator like a left bracket is made from stacking left-to-right glyphs vertically. I currently use a sequence of blocks stacked vertically to handle this and it seems to work quite nicely. While I have some reservations about inheriting from RenderBlock, for now this seems like the right thing to do. My only other option would be somehow "duplicate" the line layout--which is something I have no justification for right now. -- --Alex Milowski "The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered." Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] RenderObject is-a boolean methods
My understanding is that RenderObject::isRenderMathMLBlock() is the
right approach, yes. Although if MathML base renderer (like
RenderBoxModelObject or RenderSVGModelObject), then an
isMathMLModelObject() would be even better. Then you only add one
method to RenderObject and the rest can go on your base renderer.
Hyatt will likely have further thoughts.
-eric
On Mon, Jan 4, 2010 at 11:35 AM, Alex Milowski wrote:
> There are a number of "isSomething" methods used by different parts of
> the rendering tree code to determine the type of a render object. To add
> something similar for MathML, I'll need to add my own methods here.
>
> I've chosen to add a single method:
>
> virtual bool isRenderMathMLBlock() const { return false; }
>
> and then add my own isRenderMathML{whatever} to my own class
> named RenderMathMLBlock so that I don't need to keep touching
> the RenderObject class.
>
> Does that sound like the right approach or is there some other preferred
> design pattern floating around out there?
>
> I suppose these boolean methods are possibly faster than some kind
> of extensible type coding system but it does seem like it drives endless
> changes to these typing methods. Of course, there aren't that many
> new rendering objects introduced and so those changes can be kept
> to a minimum. ...just a thought.
>
> --
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
>
> Bertrand Russell in a footnote of Principles of Mathematics
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] RenderObject is-a boolean methods
There are a number of "isSomething" methods used by different parts of
the rendering tree code to determine the type of a render object. To add
something similar for MathML, I'll need to add my own methods here.
I've chosen to add a single method:
virtual bool isRenderMathMLBlock() const { return false; }
and then add my own isRenderMathML{whatever} to my own class
named RenderMathMLBlock so that I don't need to keep touching
the RenderObject class.
Does that sound like the right approach or is there some other preferred
design pattern floating around out there?
I suppose these boolean methods are possibly faster than some kind
of extensible type coding system but it does seem like it drives endless
changes to these typing methods. Of course, there aren't that many
new rendering objects introduced and so those changes can be kept
to a minimum. ...just a thought.
--
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."
Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Extra privileges for local javascripts with WebkitGtk
Yes. This is exactly the problem that isolated worlds is trying to solve. The implementation in the bindings to the V8 JavaScript engine is complete. I believe the implementation in the JavaScriptCore bindings is complete as well. You should look for some APIs with the words "isolated" and "world" in their name. If you'd like a high-level explanation of what this feature does, see Section 4.3 of http://www.adambarth.com/papers/2010/barth-felt-saxena-boodman.pdf (particularly the paragraph named "isolated worlds"). Enjoy! Adam On Mon, Jan 4, 2010 at 9:57 AM, Darin Adler wrote: > WebKit contributors have developed a feature called “isolated worlds” to > handle requirements like this. > > But I don’t know where we are in the implementation of that feature. Perhaps > one of the people working on isolated worlds could comment on its current > status. > > -- Darin > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Extra privileges for local javascripts with WebkitGtk
WebKit contributors have developed a feature called “isolated worlds” to handle requirements like this. But I don’t know where we are in the implementation of that feature. Perhaps one of the people working on isolated worlds could comment on its current status. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] LayoutTests new-window-opener
Hello, Just an question on this expected : LayoutTests/fast/dom/Window/new-window- opener-expected.txt In test you have this text : On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". But in expected you have : Toolbar FAIL newWin.toolbar.visible should be true. Was false. PASS newWin.toolbar.visible is false FAIL newWin.toolbar.visible should be true. Was false. PASS newWin.toolbar.visible is false Statusbar FAIL newWin.statusbar.visible should be true. Was false. PASS newWin.statusbar.visible is false FAIL newWin.statusbar.visible should be true. Was false. PASS newWin.statusbar.visible is false Locationbar FAIL newWin.locationbar.visible should be true. Was false. PASS newWin.locationbar.visible is false FAIL newWin.locationbar.visible should be true. Was false. PASS newWin.locationbar.visible is false PASS window.successfullyParsed is true Normaly here I should see only "PASS" messages and it's not the case. Is it an error or the message is not correct ? Regards Mario Bensi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Extra privileges for local javascripts with WebkitGtk
Hi guys, for the uzbl browser (www.uzbl.org) we want to give users the ability to execute their own javascripts with extra privileges. Extra privileges = executing uzbl commands which can do many actions, such as executing shell commands. But at the same time, we want js scripts from the users to be able to modify the DOM of webpages. The extra privileges should obviously never become available to javascripts from websites. Currently we implemented the so-called "Uzbl" object which has a 'run' method. See the 'eval_js' function in http://github.com/Dieterbe/uzbl/blob/master/uzbl-core.c for our current implementation. and 'JAVASCRIPT HELPER OBJECT' at http://github.com/Dieterbe/uzbl/blob/master/README It was brought to my attention that given the way js works (you can change core DOM functions such as window.addEventListener or document.createElement), stack/object inspection, and maybe more (mind you: I'm not familiar with how JS works at all, hence this mail) the Uzbl object can "leak" to the scope of js scripts of website, which is quite bad. See for a sample exploit: http://lists.uzbl.org/pipermail/uzbl-dev-uzbl.org/2010-January/000586.html Can you advise us on how to tackle this topic? Is there a clean solution for this problem? Thanks, Dieter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch status display on bugs.webkit.org
Adam Barth wrote: As we bring more bots online, this user interface should scale better than posting lots of "pass" comments. If folks like this display, we can incorporate it into bugs.webkit.org directly. +1 for including this in the site directly! Cool stuff! Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about Heap::markConservatively.
Hi Pattin, > b. Cound somebody tell me the crash reason about? I think maybe program > access non-align(4bytes) memory address? Did you implement JSC::currentThreadStackBase correctly? It needs to return the base address of the stack (bottom or top, depending on platform) as the starting point for GC. Could be a cause. Dominik Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
