Re: [webkit-dev] Fwd: Point 3 of the WebKit Style Guidelines (indenting code inside namespaces in headers)
On Wed, Oct 7, 2009 at 10:02 PM, Eric Seidel wrote: > Now from the right email address... > > > -- Forwarded message -- > From: Eric Seidel > Date: Thu, Oct 8, 2009 at 1:02 AM > Subject: Re: [webkit-dev] Point 3 of the WebKit Style Guidelines > (indenting code inside namespaces in headers) > To: David Levin > Cc: Maciej Stachowiak , webkit-dev Development > > > > Did we ever come to resolve about this issue? > > Can we turn it into bugs if that's the case? > > Or do we need a vote? :) > > No need to vote (we don't vote on such things). Someone just needs to put the change up for review. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: Point 3 of the WebKit Style Guidelines (indenting code inside namespaces in headers)
Now from the right email address... -- Forwarded message -- From: Eric Seidel Date: Thu, Oct 8, 2009 at 1:02 AM Subject: Re: [webkit-dev] Point 3 of the WebKit Style Guidelines (indenting code inside namespaces in headers) To: David Levin Cc: Maciej Stachowiak , webkit-dev Development Did we ever come to resolve about this issue? Can we turn it into bugs if that's the case? Or do we need a vote? :) -eric On Tue, Sep 22, 2009 at 8:45 PM, David Levin wrote: > > > On Tue, Sep 22, 2009 at 5:37 PM, Maciej Stachowiak wrote: >> >> On Sep 22, 2009, at 1:06 PM, David Hyatt wrote: >> >>> I had thought that we resolved ages ago that we would no longer be >>> indenting code inside namespaces in header files, since that just results in >>> the entire class declaration being pointlessly indented. >>> >>> This is point 3 on the page: >>> >>> http://webkit.org/coding/coding-style.html >>> >>> I'd like to reverse the Right and Wrong examples to fix this. >>> >>> Are there any objections to this change? I know a few months ago, people >>> agreed (notably Maciej) that there was no longer any point to essentially >>> indenting the entire file's contents (when we already don't do this in .cpp >>> files). >> >> I like this change (even though it's hard to make Emacs play along). > > Is there a way to get Emacs to auto-indent this correctly? :'( > > > ___ > 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] How does Zooming Work?
After chatting with David Hyatt, the answer seems to be, in my own words, "smack your fingers with a ruler." My current layout() method leaves with the RenderMathRow instance and some of its descendants needing layout. That's a violation of the API contract for layout(). I should make sure I don't need layout at the end by adding: setNeedsLayout(false); That would have caused my current implementation to fail to do what I wanted. The simple fix for me is to call RenderBlock::layout() again within the context of my method. If that causes other problems, I'll have to deal with those problems individually. For now, that fixes my problems with zoom. -- --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] How does Zooming Work?
On Tue, Oct 6, 2009 at 9:09 PM, Dan Bernstein wrote:
>
> On Oct 6, 2009, at 8:49 PM, Alex Milowski wrote:
>
>> What exactly happens during a zoom (command +/-) ?
>
> Depends on the flavor of zoom (“full-page” zoom vs. text-only zoom), but in
> both cases, a full style recalculation for the document is forced.
>
>> I have code that works well but layout doesn't seem to happen after
>> a zoom in/out operation. If I then resize the window, that forces a
>> layout for the zoomed size and things adjust themselves
>> appropriately (because layout() eventually gets called).
>>
>> So, what sequence of events happens after a zoom?
>
> Frame::setZoomFactor() calls Document::recalcStyle(Force). If after that the
> document has a renderer (which would be a RenderView) and that renderer is
> marked for layout, then FrameView::layout() is called, which will call
> RenderView::layout() and recursively lay out every render tree object marked
> as needing layout.
>
> One explanation for what you’re seeing would be that as your objects’ style
> changes, they fail to call setNeedsLayout() (or
> setNeedsLayoutAndPerfWidthsRecalc()), and therefore layout doesn’t occur at
> that time. An alternative, less likely, explanation is that your objects
> have anonymous children, but they don’t propagate the style changes
> correctly to those children.
The style changes seem to be propagating properly. I've dug into this
quite a bit more. Here's the layout method for mrow that attempts to
notify the math operators to stretch to a certain height:
void RenderMathRow::layout() {
RenderBlock::layout();
// calculate the maximum height
int maxHeight = 0;
int currentHeight = offsetHeight();
RenderObject* current = firstChild();
while (current) {
if (current->isBoxModelObject()) {
RenderBoxModelObject* box = toRenderBoxModelObject(current);
// Check to see if this box has a larger height
if (box->offsetHeight()>maxHeight)
maxHeight = box->offsetHeight();
}
current = current->nextSibling();
}
if (maxHeight!=currentHeight) {
style()->setHeight(Length(maxHeight,Fixed));
setNeedsLayoutAndPrefWidthsRecalc();
// notify contained operators they may need to relayout their
stretched operators
current = firstChild();
while (current) {
if (current->isRenderMathOperator()) {
RenderMathOperator* mathop = toRenderMathOperator(current);
mathop->stretchOperator(maxHeight);
}
current = current->nextSibling();
}
}
}
I modify the style of the mrow (a copy of the style) and change the height
of the container (the mrow). This code correctly works the first time and
will adjust properly after a zoom in/out if you resize the window.
The stretchOperator() method marks the child as needing layout. As the
children of mrow are stacked as a set of inlines (mostly likely all
inline-block),
there must be something that is not propagating.
Also, I notice on a zoom in that the render tree for the MathML is
being partially
recreated. New instances of the children of mrow are created. Their initial
layout() call then does not have the new maxHeight value. Afterwards, they
are marked for layout just as in the initial layout.
I've narrowed the problem down to this sequence of events:
1. RenderMathRow::layout() is called (from the outside)
2. RenderMathRow::layout() calls RenderBlock::layout()
3. Subsequent calls to RenderMathOperator::layout() are causes by (2). The
stretch height has not been set at that moment.
4. If the height has changed:
a. The height of RenderMathRow is set and it is told it needs layout
b. Each RenderMathOperator child is notified of the stretch height and
told it needs layout.
5. RenderMathRow::layout() is called (from the outside)
6. RenderMathRow::layout() calls RenderBlock::layout()
7. Subsequent calls to RenderMathOperator::layout() are causes by (2). The
stetch height is now set properly and the height of the
inline-block is now correct.
What is interesting is that after a zoom, 1-4 happen. 5-7 only happen
after a resize
event. My suspicion is that even though the RenderMathRow instance has marked
itself and its RenderMathOperator children as needing layout, that is
somehow not
noticed until the window resize.
I can solve this right now by adding another call to
RenderBlock::layout() in the
RenderMathRow::layout() method. I shouldn't have to do that and I've
noticed that
such direct "double" calls can cause other problems.
Any ideas what is wrong? Do I need to notify the parent of
RenderMathRow somehow?
--
--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
Re: [webkit-dev] Regarding WebKit Support Libraries
Hi Jason, We actually changed our network implementation long ago. The one that is in sync with the tree is part of the private support library and we won't be releasing source for it at this time. The one that is in the repository and not in sync is in fact not used, but at one time did work. On 7-Oct-09, at 4:40 PM, Jason Rukman wrote: George, I was wondering if you are intending to push this implementation into the current webkit respository at some point. It looks like the code in your repository is out of sync with the current tree. If anyone else has had success working with wininet on windows we'd like to know so we can also use it to enable file caching and HTTPS support. I haven't seen how we can do file caching with curl. Thanks, Jason. BSquare http://www.bsquare.com Daniel Zucker wrote: Hi Alp and Brent, My vote is to use Wininet. Hi Daniel, You can register your vote by writing and offering to maintain a WinINet http backend. We have already done one. You can find the source for it in our source drop for WinMobile. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Regarding WebKit Support Libraries
George, I was wondering if you are intending to push this implementation into the current webkit respository at some point. It looks like the code in your repository is out of sync with the current tree. If anyone else has had success working with wininet on windows we'd like to know so we can also use it to enable file caching and HTTPS support. I haven't seen how we can do file caching with curl. Thanks, Jason. BSquare http://www.bsquare.com >> Daniel Zucker wrote: >>> Hi Alp and Brent, >>> >>> My vote is to use Wininet. >> >> Hi Daniel, >> >> You can register your vote by writing and offering to maintain a >> WinINet >> http backend. > >We have already done one. You can find the source for it in our >source drop for WinMobile. > >-- >George Staikos >Torch Mobile Inc. >http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
06.10.2009, в 0:39, Maciej Stachowiak написал(а): For now, there are no SocketStreamHandle implementation. so even enabling WebSockets in Settings, it is the almost same that the feature is not available.. As far as I'm concerned, that's ok for testing, even though we would not want to ship that way. If the state is so bad that we don't even want people testing, then the feature should be compiled out entirely. In my opinion, anyway. Without a SocketStreamHandle implementation, there is probably nothing people can test - as there will be no network activity at all. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Partial SVG repaint
SVG was designed to support this, it's just not been turned on yet. It would be one little patch and a lot of little patches afterwards to fix things that break. :) You'd just add a checks in RenderSVGContainer and RenderPath to see if the dirty rect intersected the repaintRectInLocalCoordinates. http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderSVGContainer.cpp#L92 http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderPath.cpp#L115 I think that could add a bunch of under-painting bugs, but theoretically if of stored bounding box calculations are correct, then such a change should be fine. I'm not sure I would suggest such a change as your first change to WebKit though. It could have lots of fallout. :) -eric On Tue, Oct 6, 2009 at 4:05 PM, Patrick Roland Gansterer wrote: > I want to fix https://bugs.webkit.org/show_bug.cgi?id=30055. > > What is the prefered solution? > Where is the best place to start? > If i start the work i might ends up in one big patch. So what are the code > areas i can create single patches from? > > Patrick > ___ > 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] compileOpCallSetupArgs
Hi Zoltan. Sounds like a bug. (I tend to dislike #ifdefs like JIT_OPTIMIZE_CALL because of their tendency to fall prey to bit rot like this.) Loading the callee into regT1, regT0 is best. I'd recommend changing ! JIT_OPTIMIZE_CALL to respect that convention. Geoff On Oct 7, 2009, at 6:54 AM, Zoltan Herczeg wrote: Hi, I am not sure this is a bug, so I am curios about your opinion. Currently, I am trying to enable JSVALUE32_64 on ARM. First step, as usual, with all optimizations disabled. Unfortunately, I got a crash. If JIT_OPTIMIZE_CALL is disabled, callee is loaded to regT1 and regT2, while if enabled, to regT0 and regT1. However, there is only one type of compileOpCallSetupArgs, which presumes that callee is in regT0 and regT1. If this is indeed a bug, which way should I choose: change compileOpCall or put ifdef-s to compileOpXXXSetupArgs functions? Zoltan ___ 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] compileOpCallSetupArgs
Hi, I am not sure this is a bug, so I am curios about your opinion. Currently, I am trying to enable JSVALUE32_64 on ARM. First step, as usual, with all optimizations disabled. Unfortunately, I got a crash. If JIT_OPTIMIZE_CALL is disabled, callee is loaded to regT1 and regT2, while if enabled, to regT0 and regT1. However, there is only one type of compileOpCallSetupArgs, which presumes that callee is in regT0 and regT1. If this is indeed a bug, which way should I choose: change compileOpCall or put ifdef-s to compileOpXXXSetupArgs functions? Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit apocrypha + benchmarking
On Wednesday 07 October 2009 12:36:24 Akos Kiss wrote: > Hi All, > > I hope that a lot of you are regularly visiting our benchmarking site at > http://www.sed.hu/webkit :) . As you might know, the performance and > memory consumption of JavaScriptCore is measured on x86 Linux and Mac > platforms, on several benchmark suites, on a regular basis, and > visualized in the form of nice charts. Do you think you could use HTML5/Canvas for the charts like the Chromium folks do? And do you think it would be possible to document the setup? Specially how the memory usage is determined and last would be the question if you would be willing to run some webkit tests as well? The reason I ask is that I have recently started building a page loading test for the poor[1] and a script/application to mirror content. holger [1] http://trac.webkit.org/wiki/QtWebKitPerformanceWork ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit apocrypha + benchmarking
Hi All, I hope that a lot of you are regularly visiting our benchmarking site at http://www.sed.hu/webkit :) . As you might know, the performance and memory consumption of JavaScriptCore is measured on x86 Linux and Mac platforms, on several benchmark suites, on a regular basis, and visualized in the form of nice charts. Moreover, we also have a website called WebKit Apocrypha at http://webkit.sed.hu/, where we used to write blog posts. (We have been quite busy with other things in the last weeks - shame on us - but new posts are ahead!) Now, we are merging these two together. From now on, the benchmark charts are available as an integrated part of our Apocrypha site: http://webkit.sed.hu/benchmark . The old site is still alive, but not for long. Integration is not the only new issue, we started benchmarking on ARM as well. Come, and have a look! All comments are very welcome! (BTW, if you do an advanced query for the results of the last month - say, from 7th of September till 7th of October - you can see that a performance improvement happened on 1st of October on all platforms. That's when TCmalloc got enabled by default for the Qt port. http://trac.webkit.org/changeset/48976 ) Regards, Akos ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [chromium-dev] Learning Webkit: High Level Webkit overview?
hi, My comments below. Pls correct me if my understanding is inaccurate. On Wed, Oct 7, 2009 at 2:37 AM, Buakaw San wrote: > Thanks for your input. I have attached the flow chart for the Mozilla's > Layout engine, how would you say the WebKit data flow differs from this > diagram? > > I'm a little confused about when the CSS gets parsed. > The default style rules (User/UA style sheet) gets parsed in Document::attach() which happens when documents gets transitioned to commit state (i.e. the moment you receive some data). The page style (inline
