Re: [webkit-dev] PSA: More debugging show* methods!
This looks very useful! Any chance you might be able to add some documentation to the wiki for these? Best regards, Jeremy On Fri, May 27, 2011 at 3:29 AM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, No more gdb crashes! We've recently added the following show* methods in debug builds: - r85512 http://trac.webkit.org/changeset/85512 - InlineBox::showLineTreeForThis, InlineTextBox::showBox, RenderObject::showRenderTreeForThis, RenderObject::showLineTreeForThis - r87438 http://trac.webkit.org/changeset/87438 - WTFString::show, AtomicString::show - r87453 http://trac.webkit.org/changeset/87453 - CSSStyleDeclaration::showStyle Best, Ryosuke Niwa Software Engineer Google Inc. ___ 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] Font Name
There are a couple steps missing, but this hits most of the important
points.
I think one could turn such into a blog post with diagrams if so desired.
-eric
On Sat, May 21, 2011 at 5:55 PM, Mustafizur Rahaman
mustaf.h...@gmail.comwrote:
Hi,
When you are drawing some text, you create a RenderText(RenderObject)
which has all the rendering info the m_style of RenderText has the style
info required to render the text.
Let's consider the following style data I have in my html page
style type=text/css
body.rahaman{
font:30px courier;
}
/style
body class=rahaman Rahaman /body
Once the HTMLTreeBuilder parses the token, it creates HTMLStyleElement
CSSStyleSheet then asks the CSSParser to parse the StyleSheet. From there
it comes to CSSParser::parseValue()=CSSParser::parseFont() as the I have
only used font property
We create a FontValue (which contain all the attribute a font property can
have like style, size, variant, family etc= in this font_family, you can
actually see the font name you have used ). In CSSParser::parseFont, we
populate the FontValue structure (you can find the font family name in
font-family), calls CSSParser::addProperty() where we create a CSSProperty
with the FontValue/CSSValue being passed this property is being stored in
CSSParser::m_parsedProperties.
Then we call CSSParser::createStyleRule where we used the
m_parsedProperties mentioned before to create a CSSMutableStyleDeclaration
set this declaration for the CSSRule.
We then create CSSStyleSelector and call CSSStyleSelector::styleForElement
for the root element. Here somehow (I don't have much details what happens
in berween but figured out that we retrieve the same
CSSMutableStyleDeclaration mentioned above) call
CSSStyleSelector::applyProperty(). Here each StyleSelector has its
RenderStyle (m_style), where from we retrieve the FontDescription add the
properties accordingly. On the other hand, each RenderObject (the
corresponding node in the RenderTree for a node in DOM tree) has
RenderStyle, which gets the value we retrieved above.
Finally we call GraphicsContext::drawText() passing the Font which we have
retrieved from the RenderStyle we dsicussed above.
I am not sure if this is what you were looking for, I just shared whatever
I knew of the related area. Please let me know if you need anything else.
Thanks,
Rahaman
On Fri, May 20, 2011 at 12:22 AM, Soheil Servati Beiragh
sserv...@yahoo.com wrote:
Hi
I want to know after webkit parses the html file where does it save the
font that is used for text? It definitely won't save a name for the font but
there should be some kind of index or sth to tell the rendering engine which
font is being used.
Thanks in advance
*Soheil Servati Beiragh*
*PhD Candidate, ECE Department,
*
*Research Center for Integrated Microsystems,*
*University of Windsor.*
Room 268 Essex Hall
401 Sunset Avenue
Windsor, Ontario
Canada, N9B 3P4
Phone: 519-253-3000 Ext 3396
Email: serv...@uwindsor.ca
___
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 mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On May 28, 2011, at 5:15 PM, Geoffrey Garen wrote: This came up in https://bugs.webkit.org/show_bug.cgi?id=59604. My personal preference is against const member functions because they force many error-prone code changes: introducing a const forces the transitive closure of all potential callees to change their signatures recursively, and if you get this wrong in the case of a virtual function, you introduce a very subtle set of bugs. I think we do currently overuse const. There are many objects that are not really data holders, and it does not seem all that helpful to distinguish a const member function on such an object. I don't see much upside to const member functions because they're just an unenforced convention: sub-object and mutable data members are still non-const inside a so-called const function, and you can always const_cast away so-called const-ness, as WebKit currently does in 483 places. I don’t fully agree. Although const is not an airtight mechanism, it can be helpful to make clear which functions are intended to have side effects and which are not. It’s helped me notice programming mistakes in the past. I don’t think the presence of mutable invalidates the helpfulness of const. I also don’t think the total number of calls to const_cast in WebKit is a good metric of how well const is working as a design pattern. Many of those calls are required due to working with libraries outside of WebKit such as CoreFoundation. I think we should stop using const member functions on classes where the distinction is weak and it’s not paying off. The classes that immediately come to mind are the DOM elements and render tree nodes. Having a const pointer to one node in a tree is not all that meaningful since the const-ness is immediately lost if you move to a neighbor. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cherry-Pick Bug Comments
I think we should be able to make everyone happy if we handle these the same way we handle the EWS and style bots. The data lives on another server (appengine in this case) and is brought into the bugzilla page via an iframe. We could have an iframe for the Qt release that is empty by default, but shows a link to the release when that patch has been integrated into a branch. Ojan On Fri, May 27, 2011 at 2:29 PM, James Robinson jam...@google.com wrote: I find these cherry-pick bug comments annoying and hope that you will stop generating them. There are many ports that make releases based off of WebKit trunk, and all of them have some notion of release branches that contain cherry-picked revisions, reverts, etc. As a developer it's nearly always irrelevant to me whether a given patch is cherry-picked into a given Qt release or not, just as it would be to know if that revision was cherry-picked into a given Gtk, EFL, Safari, or Chromium release branch. When I do need to know the status of a specific branch, I look in the port-specific location of the branch to see what happened. For example, to see what's in a given chromium release I look in the appropriate subdirectory of http://trac.webkit.org/browser/branches/chromium. For the Safari 534 branch, http://trac.webkit.org/browser/branches/safari-534-branch etc. I would recommend that the people who work on QtWebKit figure out a way to track revisions in their release branches in a way that does not involve spamming non-Qt bugs on bugs.webkit.org or developers who aren't working directly on Qt. - James On Fri, May 27, 2011 at 10:27 AM, Antonio Gomes toniki...@gmail.comwrote: An important question: besides the notification e-mails, does the rest of our release process bothers someone? Not me. It works fine and is very transparent. -- --Antonio Gomes ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CamanJS Benchmark: what's wrong with WebKit
Hi all, I've found this blog: http://blog.meltingice.net/programming/camanjs-benchmark-firefox-4-beta-kicking-chromes-ass/ I tested and found the following results on a Core2 Duo 2.66 GHZ /Fedora 15 all webkit ports are really far from the firefox 4 :( firefox4 Arora0.11.0(webkit 533.3) chrome (11.0.696.71)midori(webkitgtk-1.4.0) brightness320ms12570ms3239ms 7613ms clipi 352ms23830ms 2723ms 7048ms colorize 313ms34424ms 3461ms 6474ms contrast937ms29330ms 4758ms 7593ms gamma 376ms49212ms 3920ms 6283ms greyscale 277ms28935ms 3796ms 6150ms hue 853ms33353ms3675ms 6660ms invert228ms37749ms2684ms 6118ms noise247ms24039ms3325ms 6195ms saturation 488ms17916ms 2943ms 6845ms sepia244ms31918ms 3420ms 6239ms regards. Haithem. -- * If you ask a question - you will be a fool for 5 minutes, otherwise ignorant for rest of your life * ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
