Re: [webkit-dev] Intent to implement in Blink: CSS properties break-{after, before, inside}

2016-01-29 Thread David Hyatt
https://bugs.webkit.org/attachment.cgi?id=270221=review

> On Jan 21, 2016, at 8:35 AM, Morten Stenshorne <msten...@opera.com> wrote:
> 
> Thanks for your quick response!
> 
> David Hyatt <hy...@apple.com> writes:
> 
>> We are in favor of those properties. If you want to talk about “avoid”
>> specifically offline, I outlined a plan for implementing that property
>> in one of the webkit bugs (I’ll have to hunt down the link). I think
>> it basically needs to work a bit like margin collapsing in the sense
>> that you need to propagate out knowledge of the break intent at the
>> top and bottom of blocks, and then “collapse” with adjacent blocks to
>> determine what the break intent should be at a given position.
>> 
>> dave
>> 
>>> On Jan 19, 2016, at 1:12 PM, Morten Stenshorne <msten...@opera.com> wrote:
>>> 
>>> Hello WebKit! :)
>>> 
>>> I'm planning to implement the CSS properties break-after, break-before
>>> and break-inside [1] in Blink. As part of that process, I need to ask
>>> other browser vendors about their views / plans regarding this web
>>> platform feature. I'd especially like to know if you have anything
>>> against implementing these properties (apart from priorities).
>>> 
>>> Thanks in advance!
>>> 
>>> [1] https://www.chromestatus.com/feature/5630943616303104
>>> 
>>> -- 
>>>  Morten Stenshorne, developer, Opera Software ASA 
>>> -- http://www.opera.com/ -
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> 
> 
> -- 
>  Morten Stenshorne, developer, Opera Software ASA 
> -- http://www.opera.com/ -

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Intent to implement in Blink: CSS properties break-{after, before, inside}

2016-01-19 Thread David Hyatt
We are in favor of those properties. If you want to talk about “avoid” 
specifically offline, I outlined a plan for implementing that property in one 
of the webkit bugs (I’ll have to hunt down the link). I think it basically 
needs to work a bit like margin collapsing in the sense that you need to 
propagate out knowledge of the break intent at the top and bottom of blocks, 
and then “collapse” with adjacent blocks to determine what the break intent 
should be at a given position.

dave

> On Jan 19, 2016, at 1:12 PM, Morten Stenshorne  wrote:
> 
> Hello WebKit! :)
> 
> I'm planning to implement the CSS properties break-after, break-before
> and break-inside [1] in Blink. As part of that process, I need to ask
> other browser vendors about their views / plans regarding this web
> platform feature. I'd especially like to know if you have anything
> against implementing these properties (apart from priorities).
> 
> Thanks in advance!
> 
> [1] https://www.chromestatus.com/feature/5630943616303104
> 
> -- 
>  Morten Stenshorne, developer, Opera Software ASA 
> -- http://www.opera.com/ -
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Zoltan Horvath is now a WebKit reviewer

2014-06-11 Thread David Hyatt
Hi all,

I'm pleased to announce that you now have someone new to pester for layout and 
rendering patch reviews!

Zoltan Horvath is now a WebKit reviewer. He has done some excellent work in 
layout and rendering. He has primarily worked on shapes code, but also did 
useful refactoring in areas like line layout.

Congratulations, Zoltan!

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Implement ruby-overhang

2013-04-17 Thread David Hyatt
On Apr 17, 2013, at 2:26 AM, Yuki Sekiguchi yuki.sekigu...@access-company.com 
wrote:

 Hi,
 
 I'd like to add support for ruby-overhang.
 The spec for this feature can be found here:
 http://www.w3.org/TR/css3-ruby/#rubyover
 
 I'm working it at this bug
 https://bugs.webkit.org/show_bug.cgi?id=114678
 
 My concern is that this patch changes the default behavior of
 overhanging ruby text.
 CSS spec says that initial value is none, but current behavior is like 
 auto.


I believe auto is a better initial value than none. We should make the initial 
value auto for now and try to get the spec changed.

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] -khtml- and -apple- CSS prefixes

2013-03-01 Thread David Hyatt
I agree with you that this would be pretty terrible. We definitely don't want 
developers doing that.

dave

On Feb 28, 2013, at 8:02 PM, Adam Barth aba...@webkit.org wrote:

 I noticed this comment on the Hacker News thread about Paul Irish's
 recent blog post:
 
 ---8---
 CSS parsing is the same, though. Slurping up your CSS and turning it
 into CSSOM’s pretty standard. Yeah, though Chrome accepts just the
 -webkit- prefix whereas Apple and other ports accept legacy prefixes
 like -khtml- and -apple-.
 
 Using this information, can you target Chrome with the webkit- prefix
 and Safari with the apple- prefix? Specifying the apple- prefix after
 webkit- will ensure that Safari uses that one, right?
 ---8---
 
 http://news.ycombinator.com/item?id=5302150
 
 If developers start using this technique, it might be harder to remove
 these prefixes in the future.  Chromium's experience removing these
 prefixes has been quite positive.  We ran into one compatibility
 problem on apple.com, which Apple was gracious enough to fix.
 
 I'd recommend that the rest of the ports disable
 ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml-
 and -apple- CSS prefixes before it's too late.
 
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CSS Masking in WebKit

2012-08-31 Thread David Hyatt
This is great! I'd like to be the goto reviewer for any changes you make on the 
CSS Masking side, since I implemented the original code. I also want to be kept 
in the loop if any changes are made to the way any of the -webkit-mask-* 
properties are specified. There are some interesting differences (especially in 
default values) when compared with the corresponding background/border-image 
properties, and I want to make sure all of that is well understood.

Also, it's important to make sure if there are any deviations/changes, that the 
-webkit-prefixed versions of these properties don't change behavior. Backwards 
compatibility is extremely important here. You'll notice that the way I 
preserved backwards compatibility on border-image for example was to go ahead 
and implement the unprefixed versions. I don't really have a good suggestion 
for how to do that here... it's possible a new prefix will be necessary.  It 
all depends on if any changes are made that would break existing code.

dave
(hy...@apple.com)

On Aug 29, 2012, at 5:41 PM, Dirk Schulze wrote:

 Hi WebKit folks,
 
 The CSS WG and SVG WG agreed to work on a CSS Masking specification [1]. 
 Basically the spec aims to specify the behavior of 
 -webkit-mask/-webkit-box-mask on WebKit browsers and SVG Mask/ SVG ClipPath 
 on Firefox.
 
 I would like to implement the specification in the next weeks and months. 
 Since masking and clipping are basic operations that use the existing 
 capabilities in all graphic libraries, and sine we are using it heavily 
 internally in WebKit already, I do not plan to introduce a new compiler flag. 
 
 However, some features will be covered by existing compiler flags like SVG 
 Mask and SVG ClipPath, allowing to disable these parts.
 
 I created a master bug that covers the work [2].
 
 Greetings,
 Dirk
 
 [1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
 [2] https://bugs.webkit.org/show_bug.cgi?id=95389
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Is the New XMLParser dead?

2012-08-29 Thread David Hyatt
On Aug 27, 2012, at 7:17 PM, Adam Barth wrote:

 My position is simple: the code is broken and unused.  As a general
 rule, we shouldn't keep broken, unused code in the tree for extended
 periods of time.  Therefore, we should remove it.

I agree with Adam. We should aggressively cull dead code from the tree. It's 
the only way to keep things tidy. I may get back to it at some point in the 
future is a fine statement, but without any firm commitment, it seems best to 
just remove the code from the tree for now. If and when someone steps up to 
actually work on it again, it shouldn't be much work to bring the code back to 
life. Forcing everyone else to deal with code that may or may not ever be 
returned to in the meantime isn't really fair to the rest of the project.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New feature: CSS3 GCPM

2012-08-23 Thread David Hyatt
On Aug 22, 2012, at 10:11 AM, Milian Wolff wrote:

 On Monday 20 August 2012 11:15:21 David Hyatt wrote:
 You're going to see some patches in the coming weeks (first one coming soon)
 to begin work on implementing:
 
 http://www.w3.org/TR/css3-gcpm/
 
 In some cases, there are going to be syntactic deviations from the spec as
 we experiment (based off discussions that are ongoing in the CSS WG), but
 in general we'll be implementing the features in the working draft.
 
 Hey there,
 
 very interesting to see you working on this! Can you tell me whether you are 
 going to work on the css3 paged-based media module next? Paired with GCPM it 
 would make WebKit a very powerful publishing tool.
 
 Thanks, take care.

There are a number of tasks happening first that are mostly about fixing what 
code is there.

Right now we have a screen pagination mode that works in terms of columns. This 
has led us to add CSS properties to hack how columns get stacked (inline 
direction or block direction), when in reality this pagination mode should be 
operating in terms of pages instead.

In addition columns and pages don't play well together in terms of nesting. You 
can't even print a page with columns on it for example, because we're incapable 
of handling that nesting.

So architecturally what's happening is that pages and columns are getting a 
complete re-write, and they're being re-implemented in terms of regions and 
flow threads. In effect, we're unifying columns, pages and CSS Regions to all 
work in terms of RenderFlowThreads that hold the actual content and 
RenderRegions that the content flows into.

RenderRegion and RenderFlowThread are the base classes used by all three models.

RenderRegionSet is a new class that derives from RenderRegion and represents a 
run of contiguous identical regions. It is going to be used by columns and 
pages and (assuming it gets adopted) by overflow:regions (dbaron's proposal for 
auto-cloning of new regions to accommodate overflow).

RenderPageSet and RenderColumnSet derive from RenderRegionSet and handle 
specialized rendering of pages and column boxes. For example, RenderPageSet 
will eventually be expanded to render all the additional boxes around pages 
that CSS3 Paged Media allows.

Columns will no longer have any code in RenderBlock. Everything will be in 
subclasses, i.e., RenderMultiColumnBlock.

When printing, RenderView will shunt its children into a RenderPageFlowThread 
and create RenderPageSets as needed for the pages (with runs of identical pages 
sharing the same page set).

The screen pagination mode that changes RenderView to have columns will be 
re-written to use a RenderPageFlowThread and RenderPageSet instead.

RenderPageSet will know about progression direction and it will determine this 
based off overflow:paged-x/paged-y instead of having a custom column-specific 
property.

Anyway, that's the basic run-down. There is a lot of architectural work to be 
done to build up this new model, but the advantage is that regions, pages and 
columns will all be nestable and work much better together (e.g., you'll be 
able to have columns thread through regions, or regions thread through pages, 
etc.).

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] New feature: CSS3 GCPM

2012-08-20 Thread David Hyatt
You're going to see some patches in the coming weeks (first one coming soon) to 
begin work on implementing:

http://www.w3.org/TR/css3-gcpm/

In some cases, there are going to be syntactic deviations from the spec as we 
experiment (based off discussions that are ongoing in the CSS WG), but in 
general we'll be implementing the features in the working draft.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New feature: CSS3 GCPM

2012-08-20 Thread David Hyatt
On Aug 20, 2012, at 11:32 AM, Peter Beverloo wrote:

 Addendum: The current Editor's Draft is significant different from the 
 published WD, and includes something similar to CSS Exclusions. Since Adobe 
 is implementing these in WebKit, it may be good to know what your ideas on 
 these are as well :-).
 http://dev.w3.org/csswg/css3-gcpm/
 
 Thanks,
 Peter

We're not touching the controversial stuff. :)

Specifically we're looking into implementing the screen pagination mode 
(paged-x/paged-y overflow) and the associated features that come along with 
that. 

We're also going to implement page floats and the general improvements to 
multi-column layout that are in the draft.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New feature: CSS3 GCPM

2012-08-20 Thread David Hyatt
On Aug 20, 2012, at 12:40 PM, Alan Stearns wrote:

 On 8/20/12 10:07 AM, David Hyatt hy...@apple.com wrote:
 
 On Aug 20, 2012, at 11:32 AM, Peter Beverloo wrote:
 
 
 Addendum: The current Editor's Draft is significant different from the
 published WD, and includes something similar to CSS Exclusions. Since
 Adobe is implementing these in WebKit, it may be good to know what your
 ideas on these are as
 well :-).
 http://dev.w3.org/csswg/css3-gcpm/
 
 
 Thanks,
 Peter
 
 
 
 
 
 We're not touching the controversial stuff. :)
 
 
 Specifically we're looking into implementing the screen pagination mode
 (paged-x/paged-y overflow) and the associated features that come along
 with that. 
 
 
 We're also going to implement page floats and the general improvements to
 multi-column layout that are in the draft.
 
 
 Do the multi-column improvements you're considering include column
 selectors?
 

Nope. I want to wait a bit and see if we get all the selector stuff reconciled 
with regions.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] paged media update?

2012-05-16 Thread David Hyatt
The difficulty with implementing paged media right now is that I'm beginning 
work on re-architecting pagination to unify columns, pages and regions. You can 
see the beginnings of this with the new multi-column classes that have been 
added to the tree.

The basic idea is that multi-column layout is being separated from RenderBlock 
and moved to a subclass, RenderMultiColumnBlock. Similar to how regions work, 
the content is represented by a flow thread and by regions that the flow thread 
is placed into. In order to avoid creating thousands of regions for columns, 
I've introduced the concept of a region set, i.e., RenderMultiColumnSet.

Pages ultimately need to be rebuilt to work the same way, i.e., to have a 
RenderPageFlowThread and a RenderPageSet. Once we have actual renderers that 
represent these objects, it will be a lot easier to make real boxes for things 
like margins, headers, footers, etc. The idea is that a set represents a 
contiguous run of objects that can all be rendered identically. If you're 
forced to have a different kind of object, e.g., a page with a different 
width/height or different style, then you break up the RenderPageSet and have 
multiple sets for each (this is similar to how regions work by default, 
although I hope to apply the same optimization to regions eventually as well if 
runs of same width/height regions are detected that are also siblings in the 
render tree).

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Handling failing reftests

2012-04-12 Thread David Hyatt
That reftest is mine. It was supposed to work cross-platform. I am happy to 
fix, but I'd need to understand what about it didn't work on other platforms. 
Can someone send me a screenshot of what it looks like?

(This is actually why I hate reftests for pagination. It's very hard to 
construct an unpaginated version that matches the paginated layout without 
tripping over stuff like this.)

Thanks
Dave
(hy...@apple.com)

On Apr 12, 2012, at 1:01 PM, Ryosuke Niwa wrote:

 On Thu, Apr 12, 2012 at 10:57 AM, Dirk Pranke dpra...@chromium.org wrote:
 This is an interesting situation; does it make sense to require our
 reftests to be generic, or is that unrealistic? I also wonder if we
 should allow  platform-specific pixel tests to coexist with
 platform-specific reference tests (since you could obviously write a
 platform-specific ref test that just displayed a single IMG, but the
 tools don't make that particularly easy).
 
 Allowing platform-specific pixel results for a ref test is a bad idea IMO. It 
 makes things even more complicated and harder to understand than it already 
 is today.
 
 - Ryosuke
 
 ___
 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] Unit Test for Page Breaks / absolute coordinates in PrintContext::pageNumberForElement

2012-03-29 Thread David Hyatt
Do you have a bug for this work? I'm not really sure what you're trying to 
accomplish… avoiding page breaks in a table row does not seem correct to me.

dave

On Mar 29, 2012, at 8:23 AM, Milian Wolff wrote:

 Hey there,
 
 I'm trying to write a unit test for my layouting patch, that prevents page 
 breaks in table rows. So far, I've extended the layoutTestController with a 
 pageBreaksInElementById function, similar to pageNumberForElementById.
 
 The logic behind the implementation is basically an extended copy of 
 PrintContext::pageNumberForElement, see e.g. [1].
 
 Now in my unit test, I call this function for every table row and ensure 
 that the return value is always 0, i.e. no page break. Turns out, that this 
 does not work as expected: My table layouting code [2] takes the offset of 
 the 
 surrounding table into account, and the visual result looks OK. The unit test 
 code ([1]) though apparently assumes absolute coordinates, which (I think?!) 
 box-pixelSnappedOffsetLeft() is *not*. What could be used instead? Also, 
 doesn't this also mean that the logic of PrintContext::pageNumberForElement 
 is 
 flawed for nested elements that are offsetted?
 
 Note btw. that the box does not have any layout state when called from 
 PrintContext::pageBreaksInElement, as such I cannot simply add a call to 
 RenderBlock::offsetFromLogicalTopOfFirstPage().
 
 Thanks
 
 [1]: http://paste.kde.org/448514/
 [2]: http://paste.kde.org/448520/
 -- 
 Milian Wolff | milian.wo...@kdab.com | Software Engineer
 KDAB (Deutschland) GmbHCo KG, a KDAB Group company
 Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
 KDAB - Qt Experts - Platform-independent software solutions
 ___
 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] CSS3 Paged Media module

2012-03-07 Thread David Hyatt
That page should be updated. We don't have that architectural flaw any longer 
since I re-wrote pagination last year.

dave
(hy...@apple.com)

On Mar 7, 2012, at 8:27 AM, Seo Sanghyeon wrote:

 2012/3/7, Milian Wolff milian.wo...@kdab.com:
 Ping? Could someone be so kind as to answer my questions below?
 
 As the following page admits, WebKit's printing architecture has
 the big flaw and in general inferior to Gecko and other engines.
 I fear you may have to rework most of WebKit's printing code to do
 what you want.
 
 http://www.webkit.org/projects/printing/
 
 -- 
 Seo Sanghyeon
 ___
 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] CSS properties vs. their JS bindings on the style object

2012-03-01 Thread David Hyatt
We shouldn't fragment WebKit engine behavior like that, especially when the 
feature is already being used to detect WebKit browsers (any WebKit-based 
browser would just be shooting itself in the foot by removing support for 
this). My vote would be to just spec it. If Trident and WebKit already do it, 
let's just spec it and then FF and Opera can implement it too.

dave
(hy...@apple.com)

On Mar 1, 2012, at 2:07 PM, Erik Arvidsson wrote:

 How about making this a compile time flag or runtime flag so that
 Apple Dashboard and iOS can keep it but let other users of WebKit
 disable it?
 
 erik
 
 
 
 
 On Tue, Feb 28, 2012 at 22:23, Benjamin Poulain benja...@webkit.org wrote:
 On Tue, Feb 28, 2012 at 9:48 PM,  t...@codeaurora.org wrote:
 Seriously, I'm not sure how to proceed on this.  It does seem to be
 outside the spec.
 
 Either update the spec or create a path to deprecate the bug.
 
 Personally, this feature sounds like it could be useful for web
 developers so updating the spec might not be a bad idea.
 
 Benjamin
 ___
 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] Subpixel Layout Update

2012-02-21 Thread David Hyatt
I had a question about the subpixel layout stuff. Right now RenderBlock is full 
of comments talking about switching to floats, .e.g.,


FIXME: Might need rounding once we switch to float, see 
https://bugs.webkit.org/show_bug.cgi?id=64021


FIXME: Change to use roughlyEquals when we move to float.
 
Are these comments obsolete? If so, can we get that code cleaned up?

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] New CSS property -webkit-control-text-overflow

2012-01-16 Thread David Hyatt
I have the same question. Can you explain why text-overflow is insufficient? I 
think in this case it would be acceptable behavior to just make text-overflow 
behave the way you want, i.e., no longer showing the ellipsis while the user is 
actively typing in the focused control seems like fine behavior even for 
text-overflow.

dave
(hy...@apple.com)

On Jan 13, 2012, at 2:45 PM, Ojan Vafai wrote:

 Is this specced anywhere? Do we need a new CSS property? Could we just make 
 text-overflow work on text inputs?
 
 On Wed, Jan 11, 2012 at 11:30 PM, Jon Lee jon...@apple.com wrote:
 Hi WebKit!
 
 I wanted to let you know that we would like to add a new CSS property 
 -webkit-control-text-overflow. It is a non-inheritable property that can only 
 be applied to single-line text inputs. Acceptable values are the same as 
 text-overflow, i.e. clip and ellipsis.
 
 When the input is set with the ellipsis value, both the placeholder and 
 inner text value of the input render with an ellipsis if the text overflows 
 and the input is not focused. When the input becomes focused, the placeholder 
 or text value renders clipped, as before.
 
 Although this is a small enhancement to text controls, we think this is 
 especially useful for authors developing on the mac platform, since the 
 analog native widgets behave similarly.
 
 The bug that tracks this is: https://bugs.webkit.org/show_bug.cgi?id=76118
 
 Jon
 ___
 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] New CSS property -webkit-control-text-overflow

2012-01-16 Thread David Hyatt
I strongly disagree with the reasoning in that post. You say:

As an author, I would find it strange that upon focus of a text input the 
ellipsis would just disappear.

I think it would be even stranger for the ellipsis not to disappear and to be 
editing a truncated version of the input field's value. What does that that 
even mean? I'd rather the author be surprised than the user!

It seems like the options are:

(1) Ignore text-overflow completely on text fields. Support a new property for 
the dynamic display of the full text when focused.
(2) Honor text-overflow strictly on text fields. Support a new property for the 
dynamic display of the full text when focused.
(3) Use text-overflow for the dynamic display of the full text when focused.

To me (3) is clearly the most attractive choice. (1) would surprise authors by 
having text-overflow not work. (2) would surprise both authors and users by 
having text-overflow work badly when you focused the control.

I see absolutely no reason to introduce a new property here, especially after 
hearing that Gecko just made text-overflow do this already. My expectation is 
that we would match Gecko's behavior and not introduce a new property.

dave
(hy...@apple.com)

On Jan 16, 2012, at 1:53 PM, Jon Lee wrote:

 There is a thread on the www-style list that discusses this point:
 
 http://lists.w3.org/Archives/Public/www-style/2012Jan/0687.html
 
 On Jan 16, 2012, at 11:41 AM, David Hyatt wrote:
 
 I have the same question. Can you explain why text-overflow is insufficient? 
 I think in this case it would be acceptable behavior to just make 
 text-overflow behave the way you want, i.e., no longer showing the ellipsis 
 while the user is actively typing in the focused control seems like fine 
 behavior even for text-overflow.
 
 dave
 (hy...@apple.com)
 
 On Jan 13, 2012, at 2:45 PM, Ojan Vafai wrote:
 
 Is this specced anywhere? Do we need a new CSS property? Could we just make 
 text-overflow work on text inputs?
 
 On Wed, Jan 11, 2012 at 11:30 PM, Jon Lee jon...@apple.com wrote:
 Hi WebKit!
 
 I wanted to let you know that we would like to add a new CSS property 
 -webkit-control-text-overflow. It is a non-inheritable property that can 
 only be applied to single-line text inputs. Acceptable values are the same 
 as text-overflow, i.e. clip and ellipsis.
 
 When the input is set with the ellipsis value, both the placeholder and 
 inner text value of the input render with an ellipsis if the text overflows 
 and the input is not focused. When the input becomes focused, the 
 placeholder or text value renders clipped, as before.
 
 Although this is a small enhancement to text controls, we think this is 
 especially useful for authors developing on the mac platform, since the 
 analog native widgets behave similarly.
 
 The bug that tracks this is: https://bugs.webkit.org/show_bug.cgi?id=76118
 
 Jon
 ___
 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] Making overflow clipping cheaper

2012-01-04 Thread David Hyatt

On Jan 4, 2012, at 2:36 PM, Julien Chaffraix wrote:

  namely RenderLayer is too generic for most cases and ends
 up hurting performance.

In what way?

Overflow clips create layers, but they do not paint or hit test at the layer 
level unless they are self-painting layers. They only become self-painting 
layers if some other property is present that causes this to happen, e.g., 
absolute positioning.

Perhaps you could point me to the specific performance problems that you're 
seeing that are caused by overflow and layers, since we already should be 
avoiding the self-painting layer code paths for overflow that doesn't need a 
layer for some other reason.

Note I have no real objection RenderLayers using mix-ins or composition to 
bring in scrolling functionality. That seems sensible if that's all you're 
planning. I'd just like to understand the performance concerns more, since it's 
not clear to me what your specific performance issues are.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Making overflow clipping cheaper

2012-01-03 Thread David Hyatt
I'd be careful in how I approach this. Some platforms are going to want 
compositing of overflow sections eventually for fast scrolling of those 
sections. RenderLayer has become the natural tie-in point for GraphicsLayer 
connections. In the future I envision overflow sections being more justified in 
having layers by virtue of the fact that they would always be composited. In a 
non-composited world, I can see why you might be tempted to yank overflow 
functionality out of RenderLayer, but in a composited world, having 
RenderLayers created for these objects makes more sense.

dave
(hy...@apple.com)

On Dec 29, 2011, at 5:49 PM, Julien Chaffraix wrote:

 Wouldn't it be better to implement better searching and paint-segmentation in
 RenderLayers then? It could also provide the same speed up for many other big
 cases.
 
 That would be worth investigating more for sure (do you mind filing a
 bug about it?). The paint search and segmentation algorithm is very
 close between RenderLayer and most RenderObjects - tables being an
 exception here as their structure enables better searching algorithms
 - which means that it would benefit everyone. I haven't spend enough
 time looking at generic scalability issues to say if there won't be
 others more important bottlenecks.
 
 I still see some upsides in attacking the reduced use case of overflow
 clips independently of what you are proposing:
 * RenderLayer has become a class handling far too many tasks so moving
 some functionality out of it is good by itself.
 * RenderObject has a better knowledge of its own structure, something
 as generic as RenderLayer would not need to be aware of.
 
 Thanks,
 Julien
 ___
 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] vertical text

2011-11-14 Thread David Hyatt
On Nov 11, 2011, at 7:59 AM, Cary Clark wrote:

 Thanks for the answer, Dave. That makes perfect sense.
 
 Why is it that the graphics context is rotated but the advances supplied to 
 Font::DrawGlyphs in the GlyphBuffer aren't?
 

Right now fonts are broken up into two categories: ones that are considered 
vertical and ones that are considered horizontal, but a vertical font 
uses a text-orientation-specific fallback when the glyphs are known to have 
flexible orientation, e.g., they could render upright or sideways depending on 
the value of the text-orientation property. 

The default value of text-orientation is vertical-right, meaning that these 
flexibly oriented glyphs should render rotated in a vertical text environment.

However, because we rotated the graphics context, we are able to simply use the 
horizontal version of the font data in this case, and this allows us to reduce 
memory usage and re-use all the cached horizontal font information. Therefore 
the flexible glyph advances are unrotated and are just the horizontal font data 
information.

Instead we rotate the glyphs that are always locked to an upright orientation 
in a vertical text environment. Those advances are the ones that are rotated. 
In effect you have a double rotation (the graphics context rotates, and then 
the inflexible glyphs get rotated again when drawing).

This may seem backwards and somewhat confusing, but I can assure you we'd have 
to write way more code if we flipped things around (and we'd consume 2x the 
memory for glyph width storage for English letters).

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] vertical text

2011-11-10 Thread David Hyatt
On Nov 10, 2011, at 4:07 PM, Cary Clark wrote:

 TL;DR: Why is the graphics context rotated when drawing vertical text?

I assume you're referring to the rotation done by InlineTextBox. The basic 
reason for the rotation was that it was a minimal change to the code and 
allowed a bunch of other drawing functions to remain unchanged. You could 
certainly eliminate the rotation, but you'd then have to patch all of the 
InlineTextBox drawing functions (underlines, selection, spell check markers, 
etc.) to be able to operate horizontally or vertically.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] old-run-webkit-tests is officially deprecated.

2011-10-27 Thread David Hyatt
Has the issue with run-webkit-tests putting pixel tests in cross-platform 
directories instead of platform-specific directories been fixed? That was the 
showstopper for me.

dave
(hy...@apple.com)

On Oct 27, 2011, at 5:00 PM, Eric Seidel wrote:

 As of this afternoon, the Apple-Win bot is the only remaining buildbot
 (to my knowledge) using old-run-webkit-tests
 (https://bugs.webkit.org/show_bug.cgi?id=38756).
 
 Unfortunately, that's not likely to change soon.  But all other
 platforms (and all other developers) besides Apple-Win should be using
 new-run-webkit-tests (it's automatically called for you when you run
 run-webkit-tests).
 
 If you're still using old-run-webkit-tests for your work, I would
 *love* to know and fix any issues you may have with NRWT.
 
 
 In the next week I'll be moving run-webkit-tests from using a
 white-list of NRWT-supported ports, to a black-list.  Meaning any
 private (or future) ports which may not be using NRWT yet will need to
 switch, or we'll need to add a special exception in run-webkit-tests
 for that port.
 
 Thank you for your patience in this process.  I've started to burn
 down the list of polish bugs
 (https://bugs.webkit.org/show_bug.cgi?id=64491) and plan to close the
 switch all bots bug (https://bugs.webkit.org/show_bug.cgi?id=34984)
 once we move run-webkit-tests from whitelisting NRWT supported ports
 to blacklisting ports which still require ORWT.
 
 -eric
 ___
 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] RefPtr/PassRefPtr Question

2011-08-31 Thread David Hyatt
I am getting complaints from check-webkit-style in a bug regarding 
PassRefPtr/RefPtr usage, and I can't figure out what I should be doing. It 
yells at me no matter what I try.

The scenario I have is that a function is wanting to transfer ownership but 
it's not doing it via a return value. Instead it is filling in a reference 
parameter.

The current code looks like this:

Caller:

RefPtrT myLocal;
bool success = myFunc(myLocal);

With the function being:

bool myFunc(RefPtrT result);

With this setup though, I get yelled at by the style checker and it tells me 
that the parameter should be a PassRefPtr. However I don't get how I can do 
that, since then I have:

PassRefPtrT myLocal;

and I get yelled at for making a PassRefPtr local variable.

What's the right way to write this code such that it will pass? Is this just a 
flaw in the style checker? It sure seems like a RefPtrT reference parameter 
should be allowed...

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Writing a new XML parser with no external libraries

2011-07-05 Thread David Hyatt
Writing a new XML parser is a complete waste of time. If libxml has problems, 
fix them. If you throw out libxml, you'd have to throw out libxslt as well.  
The end result is not worth the engineering effort it would take to build it 
and make it work better than libxml/libxslt.

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

2011-06-10 Thread David Hyatt
Just so people know, it was my recommendation that they just start with a new 
renderer and implementation.

Some other recommendations I would make here (apologies if they have been 
implemented already):

(1) Rename the current RenderFlexibleBox to put deprecated into the name, 
e.g., RenderDeprecatedFlexibleBox.

(2) The old flexbox was never patched for vertical writing modes. Please make 
sure when you build the new renderer from the ground up that you take this into 
account.

(3) Please consult with rendering experts for any changes you have to make to 
base classes, especially RenderBlock and RenderBox. We may be able to help 
simplify some of that code, especially compared to the old flexbox.

(4) Use the old flexbox code as a rough guide, but be aware of its issues, 
e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
think some of the bugs you tried to fix already should inform this somewhat.

Definitely keep rendering experts in the loop on this and have fun implementing!

Dave


 On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
 
 Hi webkit-dev,
 
 I wanted to let you know that Ojan and I plan to add flexbox layout support 
 to WebCore.  WebCore already supports an older flexbox implementation 
 (display: box), but the new spec is designed to be easier for developers to 
 understand and more powerful.  The old flexbox will still remain in WebCore 
 since none of the CSS properties overlap with the new flexbox spec.  The 
 spec can be found at: http://www.w3.org/TR/css3-flexbox/ 
 (http://dev.w3.org/csswg/css3-flexbox/)
 
 This support will be behind the ENABLE_FLEXBOX feature define 
 (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
 tracking the feature's development 
 (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to 
 eventually be enabled by all ports.
 
 I am ready to setup a buildbot for tracking the compile and flexbox related 
 layout tests.  Should I go ahead and get this added to build.webkit.org's 
 waterfall?
 
 Thanks,
 Tony
 
 ___
 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] Adding CSS Regions and Exclusions to WebKit

2011-05-26 Thread David Hyatt
On May 26, 2011, at 4:31 PM, Eric Seidel wrote:

 I appreciate that you've followed the master-bug idiom which is so common in 
 bugs.webkit.org these days!
 
 I also would *strongly* encourage you to post your changes in as small of 
 patches as possible.  Integrating features which have been developed outside 
 webkit.org is always difficult, but doing things in small (or even tiny!) 
 patches will make your life easiest in the long run.
 
 I'm happy to help review your (small!) changes if CC'd.

I've encouraged them to begin with the CSS property back end, i.e., getting the 
new properties and values in and parsed.  I think it will be a good 
introduction to our process to start there, and it will also let them get 
familiar with writing regression tests.  I think those patches are more easily 
reviewed by many people as well, unlike the layout and rendering changes, which 
are quite advanced.

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Canvas backing resolution

2011-04-06 Thread David Hyatt
He wants a way to detect Desktop zoom (which is done two different ways in 
WebKit).  It's difficult to figure out how to expose these, since Desktop zoom 
is ultimately just the CSS zoom property, which can be applied to any element 
(so folding it into a global makes little sense).  The other kind of Desktop 
zoom that involves a fixed scale factor applies a transform.  Again, transforms 
can be applied to descendant elements as well, so relying solely on what 
happened to be specified at the document level makes little sense.

I'm not really sure how to easily solve this problem.  I suppose we could just 
mix in document-level zoom and transform state into devicePixelRatio, but that 
feels inelegant to me given that individual child elements can change the zoom 
and transform.  It wouldn't necessarily be accurate.  I also don't like the 
idea of having to re-resolve style just because the zoom level changed.  That 
would just slow things down.

dave
(hy...@apple.com)

On Apr 6, 2011, at 9:17 AM, Darin Adler wrote:

 On Apr 5, 2011, at 9:52 PM, Charles Pritchard wrote:
 
 Long-story-short, can we please expose some of the CSS pixel scaling, either 
 through window.devicePixelRatio
 
 I typed javascript:alert(devicePixelRatio) in Safari on my iPhone 4, and got 
 the value 2.
 
 Isn’t this what you are asking for?
 
-- 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] Canvas backing resolution

2011-04-06 Thread David Hyatt
On Apr 6, 2011, at 3:01 PM, Charles Pritchard wrote:

 On 4/6/2011 12:32 PM, David Hyatt wrote:
 He wants a way to detect Desktop zoom (which is done two different ways in 
 WebKit).  It's difficult to figure out how to expose these, since Desktop 
 zoom is ultimately just the CSS zoom property, which can be applied to any 
 element (so folding it into a global makes little sense).  The other kind of 
 Desktop zoom that involves a fixed scale factor applies a transform.  Again, 
 transforms can be applied to descendant elements as well, so relying solely 
 on what happened to be specified at the document level makes little sense.
 The descendant elements are under the control of the author.
 
 That is, if I decide to use  body.style.webkitTransform, in my scripting 
 environment, I'm going to know that,
 because I initiated the request, and I'll add that to my calculations.
 

Yeah, that's a good point.

 I see adding a pixel ratio property to window.screen as the cleanest solution.

This seems like a decent solution to me.  Probably simplest to just match what 
WinIE did for compatibility (even though it's two properties).

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

2011-03-30 Thread David Hyatt
Yeah, I'd prefer not to prefix :not.  (Haha.) 

In fact :not used to actually support more complex selectors, and I had to dumb 
it down to pass stupid CSS 2.1 tests that deliberately checked for the lack of 
complexity... so all we'd be doing is going back to our old behavior.  We 
should probably make sure those tests are not in the current version of the 
suite though.

dave
(hy...@apple.com)

On Mar 30, 2011, at 10:50 AM, Simon Fraser wrote:

 If the change is backwards compatible (i.e. if you don't break the behavior 
 described in Selectors 3), then I don't think it needs to be prefixed.
 
 What have other vendors done?
 
 Simon
 
 On Mar 30, 2011, at 12:05 AM, Ojan Vafai wrote:
 
 What's the right thing to do for something that is in a CR spec, but the 
 draft spec for the next version has it behave differently? Specifically, in 
 Selectors 3, :not only accepts a single simple selector. In Selectors 4, it 
 accepts a comma separated list of compound selectors (a superset of the 
 Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994.
 
 I see three options:
 1. Wait until Selectors 4 hits CR before changing :not.
 2. Implement :-webkit-not to match Selectors 4 and leave :not matching 
 Selectors 3.
 3. Make :not match Selectors 4.
 
 My preference in this instance is option 3. 
 
 Ojan
 
 On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt hy...@apple.com wrote:
 As was mentioned already, we've been trying to follow the general guideline 
 of dropping the prefix when a draft hits CR and keeping it otherwise.  An 
 exception to this rule is if our syntax has not yet been updated to match 
 the CR syntax, in which case we  keep the prefix.
 
 dave
 
 ___
 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] Use of -webkit- prefix on CSS Values and Properties

2011-03-28 Thread David Hyatt
As was mentioned already, we've been trying to follow the general guideline of 
dropping the prefix when a draft hits CR and keeping it otherwise.  An 
exception to this rule is if our syntax has not yet been updated to match the 
CR syntax, in which case we  keep the prefix.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Selection Highlight for Canvas Rendering Object on Mobile Platforms?

2011-03-11 Thread David Hyatt
-webkit-tap-highlight-color: transparent is what you need I suspect (at least 
for iOS).

dave
(hy...@apple.com)

On Mar 11, 2011, at 10:33 AM, Alex Milowski wrote:

 I'm not sure this is exactly the right place to start, but I'll start
 here since the intersection of Andriod, iOS, and other developers are
 here.
 
 I've been testing some ideas for using the HTML5 canvas on mobile
 platforms versus desktop and I've notice an annoying feature on the
 mobile platforms.  It is most noticeable on Android but also shows up
 on iOS on the iPad or iPod touch devices.
 
 The application involves the use of a HTML5 canvas that intercepts
 touch events on the canvas.  Areas of a geometric image changes
 shading when touched to represent fractions of the object.  On both
 platforms, there seems to be something about focus from the touch even
 that causes a highlight for the whole box containing the canvas
 element.
 
 On iOS, a gray shaded version of the canvas shows up for a very, very
 short period of time.  It is inconsistent and depends how long the
 touch gesture is on the canvas.  Some very short touch gestures do now
 cause the highlight of the canvas.  That may be because it is just too
 short of a period of time to draw the highlight.
 
 On Andriod, any touch gesture cases a border and highlight around the canvas.
 
 Both are undesired effects.
 
 I'm trying to understand why the canvas has special highlight features
 for touch gestures over any other rendering object. Looking at the
 code, the highlight seems to be from the fact that RenderHTMLCanvas
 inherits from RenderReplaced just like RenderImage does.  It all seems
 to key off of whether the canvas is selected.  But the highlight isn't
 there for mouse clicks on desktop platforms.
 
 None of the CSS tricks (e.g. -webkit-user-select: none) seem to help
 on mobile platforms.
 
 It seems to me that on touch-enabled platforms (e.g. mobile) you
 should be able to disable this selection highlight behavior for canvas
 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
 ___
 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] Line box tree converting from int - float

2011-02-15 Thread David Hyatt
https://bugs.webkit.org/show_bug.cgi?id=54244

A patch is on its way that is going to be converting the line box tree from 
being int-based to being float-based.  All of the rounding hacks for word 
rounding and run rounding when measuring and drawing text will be eliminated.

The unfortunate side effect of such a patch, however, is that many many layout 
test results are changing on Mac (and I will be updating those test results).  
The effects on ports that use integer advances for glyphs should be minimal.  
If your platform has been returning non-integral values for advances, however, 
then expect many test results on your platform to change because of the 
improved precision.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Rebaselining render tree dumps

2010-12-06 Thread David Hyatt
RenderTreeAsTetxt has a large number of hacks in it that have been put in over 
time to keep the dumps from changing too dramatically.  Some of these include:

(1) Table cells dump incorrect dimensions and positions.
(2) Text nodes dump an incorrect bounding box position.
(3) RenderInlines don't dump their position at all.
(4) The root layer incorporates overflow when it shouldn't.
(5) The root element has a RenderLayer when there has been no need for it to 
have a RenderLayer for years.  It only has one in order to not change all the 
layout tests.

In addition there is information not being captured that would be useful to 
include in the dump.  Examples of this include:

(1) Layout and visual overflow for elements.  Right now we're completely 
dependent on repaint tests to catch changes in visual overflow.
(2) scrollOrigin for the ScrollView and for overflow sections.
(3) intrinsic padding of table cells.
(4) Transforms and relative positioning offsets

I'm sure people may have other ideas about things to include in the geometry 
dumps that aren't there right now, so send me your suggestions.

What I'd like to do is have a rebaselining day (probably after the holidays in 
January) where we just shut the tree down and all the ports rebaseline to the 
new format (with the hacks removed and any changes we want to make added).

What do people think of this idea?  How can we make sure that a rebaselining 
like this goes smoothly?

dave
(hy...@apple.com)



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Rebaselining render tree dumps

2010-12-06 Thread David Hyatt
On Dec 6, 2010, at 3:20 PM, Dirk Pranke wrote:

 I think this is a great idea. I have one suggestion and one
 potentially large, derailing comment :)
 
 Suggestion: in theory, fixing the render tree output shouldn't change
 the pixel output. So, I would suggest that as many ports as possible
 should be running (up-to-date) pixel tests when do have this flag day.
 

Yeah, that's a really good observation.  The pixel tests will help us know that 
the changes to the dump didn't regress anything.

 Large, potentially derailing comment -- would this be an opportune
 time to try and codify the intent of the rendertree output at all? We
 are geting close to having support for reftests (finally!), and we
 have dumpAsMarkup() now as well. It seems to me that a lot of the
 original intent for render tree output may have been replaced by
 better alternatives now (not that I'm suggesting we rewrite all of the
 tests prior to this flag day).
 

We definitely should be reducing the use of the render tree dump.  There are a 
number of areas where reftests are extremely difficult though.  Vertical text 
and multi-column layout are both examples where reftests are virtually 
impossible.  I think reftests for certain kinds of transforms and compositing 
could be difficult as well.

The biggest benefit of render tree dumps is that they tell you about the 
geometry and style of scrolled or clipped content.  Therefore they catch bugs 
that pixel tests don't see (and if reftests compare based off visible pixels 
then they would not see the error either).  This is the case with any tests 
that have scrolled or clipped content.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Rebaselining render tree dumps

2010-12-06 Thread David Hyatt
On Dec 6, 2010, at 4:12 PM, Dan Bernstein wrote:

 
 (6) There’s something called RenderBody ;-)

LOL yeah.  I forgot about that one.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Bools are strictly worse than enums

2010-12-03 Thread David Hyatt
On Dec 3, 2010, at 3:33 PM, Darin Fisher wrote:

 On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel e...@webkit.org wrote:
 It seems to me, that using bool types for function arguments is strictly 
 worse than using an enum.  An enum is always clearer and can be easily casted 
 to a bool if needed.
 
 doSomething(something, false);
 
 Is much less readable than:
 
 doSomething(something, AllowNetworkLoads);
 
 
 Do any C++ gurus have further information to add here?  Is my (simple) 
 analysis here incorrect?  If not, seems we should forbid boolean values in 
 multi-argument methods/constructors in our style and add checks to 
 check-webkit-style to prevent further introduction of these confusing 
 callsites.
 
 -eric
 
 
 I was under the impression that this was already an encouraged style in 
 WebKit code.  At least, I really like that is makes call-sites more 
 self-documenting.

The only exception I would make to this rule is if all the call sites use 
variables and never pass in raw true or false.  In that case there's no loss of 
readability, and whether you use an enum vs. a bool is irrelevant.

I think in general the rule should be Keep your call sites readable, and 
convert to enums if you find that the call sites are becoming inscrutable.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Bools are strictly worse than enums

2010-12-03 Thread David Hyatt
An example of nice boolean usage is:

paintTextWithShadows(context, font, textRun, 0, length, length, textOrigin, 
boxRect, textShadow, textStrokeWidth  0, isHorizontal()); GOOD!

The last parameter is a boolean indicating whether or not the text run is 
vertical text or horizontal text.  It would be unreadable if you passed raw 
true or raw false to the function, but all the call sites pass isHorizontal(), 
so it's perfectly fine.

paintTextWithShadows(context, font, textRun, 0, length, length, textOrigin, 
boxRect, textShadow, textStrokeWidth  0, true);  BAD!

dave
(hy...@apple.com)

On Dec 3, 2010, at 4:30 PM, Darin Adler wrote:

 On Dec 3, 2010, at 1:37 PM, David Hyatt wrote:
 
 The only exception I would make to this rule is if all the call sites use 
 variables and never pass in raw true or false. In that case there's no loss 
 of readability, and whether you use an enum vs. a bool is irrelevant.
 
 That’s right. There are cases where the boolean value passed in for a 
 particular argument is typically the result of a boolean expression or 
 boolean-returning function. We have definitely seen these in patch review.
 
 I think in general the rule should be Keep your call sites readable, and 
 convert to enums if you find that the call sites are becoming inscrutable.
 
 Beyond the enum guidelines, it’s also true that functions with these 
 boolean/enum arguments often indicate minor design mistakes. Many times we 
 would be better off with multiple functions rather than a single function 
 with an enum argument.
 
-- 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] Size Of Ruby Text?

2010-11-03 Thread David Hyatt
WebKit enforces a minimum font size of 9px when no explicit font size is 
specified.  This means that the font for rt cannot fall below 9px if it is 
relative to the user agent default.  It may be that we want to consider 
modifying this minimum for ruby text and allow it to go below 9px though.  I'm 
not sure.

If you make a really big Ruby (e.g., ruby style=font-size:96px and then 
modify the font-size percentage on the rt, you should be able to see it take 
effect.

We should probably just study real-world Japanese examples to see how small 
Ruby typically is allowed to get.  If it can go below 9px and still be 
readable, we should perhaps consider allowing that.

In terms of excluding Ruby text from the overall line height, I don't think the 
font-size of the rt is particularly relevant.  You just want to hack the Ruby 
to turn the ruby text into overflow rather than having it be part of the 
overall height of the inline-block.

dave
(hy...@apple.com)

On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:

 Hi,
 
 As part of my work on ruby text enhancements, I'm implementing the option of 
 not counting the height of the ruby text in the overall line height. As part 
 of this, I wanted to play with changing the size of the ruby text. I'm trying 
 to do this by changing the following lines in WebKit/WebCore/css/html.css:
 
 ruby  rt {
 display: block;
 font-size: 60%; /* make slightly larger than 50% for better readability */
 text-align: center;
 text-decoration: none;
 }
 
 However, when I change the font-size: attribute to, say, 50%, I don't see any 
 difference in the size of the ruby text. (I even tried 25% just to be sure). 
 Is this value being set somewhere else?
 
 Regards,
 Eric Mader
 
 ___
 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] Size Of Ruby Text?

2010-11-03 Thread David Hyatt
On Nov 3, 2010, at 2:05 PM, Eric Mader wrote:

 
 Of course. The website I was using has the line height set too tight for 
 correct display this way, and I just wanted to try a smaller size to see if 
 it looked better. OTOH, that site loads a style sheet that overrides the ruby 
 text font-size to 6pt, so I can't easily override it, and its' probably 
 displaying as 9pt anyhow.

We honor small explicitly set font sizes.   The 9px minimum is only enforced 
when it's impossible for the site to know what the real font size would have 
been, i.e., if you are relative to the user agent default.

dave


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Size Of Ruby Text?

2010-11-03 Thread David Hyatt
That document also states:

When the size of base characters is very small (for e.g. smaller than seven 
points), ruby which is half the size, will be even more small and illegible. In 
such cases where the size of base characters is very small, ruby is not a 
suitable method of annotation. In those cases, consider other annotation 
methods such as adding the reading in parenthesis immediately after the base 
character.

It also sounds like we need to special case Ruby elements and allow their font 
sizes to go down to about 5px instead of 9px.  Anything lower, and you're 
getting to the point where ruby was unsuitable (according to the text above) 
anyway, since the base text was so small.

I filed:

https://bugs.webkit.org/show_bug.cgi?id=48942

dave
(hy...@apple.com)

On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote:

 In printing the standard is 50% of the base text. For larger point sizes like 
 headings, the size of ruby is often smaller than 50%.
 
 http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3
 
 So, how about we default to 50% and see how they come out. Glyphs designed 
 for ruby are optimized for those small point sizes. It is possible on some 
 screen resolutions we might want to make it a bit bigger but as screen 
 resolution gets higher I think it makes more sense to stick to 50% following 
 the standard in printing.
 
 - kida
 
 On 2010/11/03, at 12:05, Eric Mader wrote:
 
 
 On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:
 
 WebKit enforces a minimum font size of 9px when no explicit font size is 
 specified.  This means that the font for rt cannot fall below 9px if it 
 is relative to the user agent default.  It may be that we want to consider 
 modifying this minimum for ruby text and allow it to go below 9px though.  
 I'm not sure.
 
 Yes, that's probably what I'm seeing. I'm using default font size, which is 
 probably 12pt.
 
 If you make a really big Ruby (e.g., ruby style=font-size:96px and then 
 modify the font-size percentage on the rt, you should be able to see it 
 take effect.
 
 We should probably just study real-world Japanese examples to see how small 
 Ruby typically is allowed to get.  If it can go below 9px and still be 
 readable, we should perhaps consider allowing that.
 
 I'm sure the detailed spec. addresses this issue. I'll review it.
 
 In terms of excluding Ruby text from the overall line height, I don't think 
 the font-size of the rt is particularly relevant.  You just want to hack 
 the Ruby to turn the ruby text into overflow rather than having it be part 
 of the overall height of the inline-block.
 
 Of course. The website I was using has the line height set too tight for 
 correct display this way, and I just wanted to try a smaller size to see if 
 it looked better. OTOH, that site loads a style sheet that overrides the 
 ruby text font-size to 6pt, so I can't easily override it, and its' probably 
 displaying as 9pt anyhow.
 
 dave
 (hy...@apple.com)
 
 Regards,
 Eric
 
 On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
 
 Hi,
 
 As part of my work on ruby text enhancements, I'm implementing the option 
 of not counting the height of the ruby text in the overall line height. As 
 part of this, I wanted to play with changing the size of the ruby text. 
 I'm trying to do this by changing the following lines in 
 WebKit/WebCore/css/html.css:
 
 ruby  rt {
 display: block;
 font-size: 60%; /* make slightly larger than 50% for better 
 readability */
 text-align: center;
 text-decoration: none;
 }
 
 However, when I change the font-size: attribute to, say, 50%, I don't see 
 any difference in the size of the ruby text. (I even tried 25% just to be 
 sure). Is this value being set somewhere else?
 
 Regards,
 Eric Mader
 
 ___
 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 mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Size Of Ruby Text?

2010-11-03 Thread David Hyatt
Yeah, that demo makes me think maybe 9px is fine after all. :)

dave

On Nov 3, 2010, at 3:56 PM, Ryosuke Niwa wrote:

 I think 5px is way too small.  Maybe 7 or 8 at least but even those are 
 really hard to read in high-resolution displays.  See demo.
 
 - Ryosuke
 
 On Wed, Nov 3, 2010 at 12:47 PM, David Hyatt hy...@apple.com wrote:
 That document also states:
 
 When the size of base characters is very small (for e.g. smaller than seven 
 points), ruby which is half the size, will be even more small and illegible. 
 In such cases where the size of base characters is very small, ruby is not a 
 suitable method of annotation. In those cases, consider other annotation 
 methods such as adding the reading in parenthesis immediately after the base 
 character.
 
 It also sounds like we need to special case Ruby elements and allow their 
 font sizes to go down to about 5px instead of 9px.  Anything lower, and 
 you're getting to the point where ruby was unsuitable (according to the text 
 above) anyway, since the base text was so small.
 
 I filed:
 
 https://bugs.webkit.org/show_bug.cgi?id=48942
 
 dave
 (hy...@apple.com)
 
 On Nov 3, 2010, at 2:29 PM, Yasuo Kida wrote:
 
 In printing the standard is 50% of the base text. For larger point sizes 
 like headings, the size of ruby is often smaller than 50%.
 
 http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#en-subheading2_3_3
 
 So, how about we default to 50% and see how they come out. Glyphs designed 
 for ruby are optimized for those small point sizes. It is possible on some 
 screen resolutions we might want to make it a bit bigger but as screen 
 resolution gets higher I think it makes more sense to stick to 50% following 
 the standard in printing.
 
 - kida
 
 On 2010/11/03, at 12:05, Eric Mader wrote:
 
 
 On Nov 3, 2010, at 8:56 AM, David Hyatt wrote:
 
 WebKit enforces a minimum font size of 9px when no explicit font size is 
 specified.  This means that the font for rt cannot fall below 9px if it 
 is relative to the user agent default.  It may be that we want to consider 
 modifying this minimum for ruby text and allow it to go below 9px though.  
 I'm not sure.
 
 Yes, that's probably what I'm seeing. I'm using default font size, which is 
 probably 12pt.
 
 If you make a really big Ruby (e.g., ruby style=font-size:96px and 
 then modify the font-size percentage on the rt, you should be able to 
 see it take effect.
 
 We should probably just study real-world Japanese examples to see how 
 small Ruby typically is allowed to get.  If it can go below 9px and still 
 be readable, we should perhaps consider allowing that.
 
 I'm sure the detailed spec. addresses this issue. I'll review it.
 
 In terms of excluding Ruby text from the overall line height, I don't 
 think the font-size of the rt is particularly relevant.  You just want 
 to hack the Ruby to turn the ruby text into overflow rather than having it 
 be part of the overall height of the inline-block.
 
 Of course. The website I was using has the line height set too tight for 
 correct display this way, and I just wanted to try a smaller size to see if 
 it looked better. OTOH, that site loads a style sheet that overrides the 
 ruby text font-size to 6pt, so I can't easily override it, and its' 
 probably displaying as 9pt anyhow.
 
 dave
 (hy...@apple.com)
 
 Regards,
 Eric
 
 On Nov 3, 2010, at 1:20 PM, Eric Mader wrote:
 
 Hi,
 
 As part of my work on ruby text enhancements, I'm implementing the option 
 of not counting the height of the ruby text in the overall line height. 
 As part of this, I wanted to play with changing the size of the ruby 
 text. I'm trying to do this by changing the following lines in 
 WebKit/WebCore/css/html.css:
 
 ruby  rt {
 display: block;
 font-size: 60%; /* make slightly larger than 50% for better 
 readability */
 text-align: center;
 text-decoration: none;
 }
 
 However, when I change the font-size: attribute to, say, 50%, I don't see 
 any difference in the size of the ruby text. (I even tried 25% just to be 
 sure). Is this value being set somewhere else?
 
 Regards,
 Eric Mader
 
 ___
 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 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] Coding style change - Indentation of forward declarations in headers

2010-11-01 Thread David Hyatt
Yeah I agree with Peter.  I think blank lines after { and before } would 
improve the readability of the 2nd example even without indentation.

namespace WebCore {

class AuthenticationChallenge;
class CachedFrame;
class HistoryItem;
class ProtectionSpace;
class ResourceLoader;
class ResourceRequest;

}

This doesn't seem worth making a special case for to me.

dave
(hy...@apple.com)

On Nov 1, 2010, at 11:49 AM, Peter Kasting wrote:

 On Mon, Nov 1, 2010 at 9:40 AM, Brady Eidson beid...@apple.com wrote:
 I think this pattern increases readability of forward declarations in headers 
 and we should change the style guidelines to specify its continued use.
 
 Thoughts?
 
 I don't find either one significantly better than the other, personally.
 
 PK 
 ___
 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] Line breaking

2010-10-29 Thread David Hyatt
Pick me! Pick me!

On Oct 29, 2010, at 1:54 AM, Adam Barth wrote:

 In looking at a bunch of web compat bugs filed in the Chromium bug
 tracker, it seems like WebKit's line breaking behavior is a major
 source of compatibility problems.  I'm currently writing a test suite
 to reverse engineer the line breaking behavior of other browsers.  I'm
 not familiar with the history of WebKit's line breaking behavior.  Who
 would be a good person to talk with about these issues?
 
 Thanks,
 Adam
 ___
 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] Focus Crash Relating to MathML

2010-10-19 Thread David Hyatt
(1) Make sure any layout methods you call do setNeedsLayout(false) at the end 
of them.
(2) Look for any early returns in any of your layout methods, since maybe you 
did an early return causing the setNeedsLayout(false) to be missed.
(3) Make sure you aren't dirtying a child for a re-layout without immediately 
doing that re-layout, e.g., don't call setChildNeedsLayout(true, false) on some 
child and then bail without doing a layout.

dave

On Oct 18, 2010, at 10:22 PM, Alex Milowski wrote:

 Most of the MathML rendering objects have a display style property value
 of inline-block.  Whenever these rendering objects are used, somehow the
 parent container gets marked as having children in need of layout.  The
 MathML math rendering object completes its layout and marks itself as
 not needing layout.  In the end, the container (e.g. the anchor element)
 render object has itself in a state where m_normalChildNeedsLayout is
 true but no child is marked as needing layout.
 
 I've gone through the MathML rendering objects and remove all uses
 of markContaingBlocksForLayout() and setNeedsLayoutPrefWidthsRecalc()
 which generally cause the container to be marked with a child needing
 layout.  These calls were unnecessary and the resulting code should be
 more efficient.
 
 In situations where the MathML does not contain a rendering object
 that is an inline-block, everything works fine.  For example:
 
 a href='#'
  math xmlns='http://www.w3.org/1998/Math/MathML'mix/mi/math
 /a
 
 Keep in mind, in the above, the 'mi' element just uses RenderInline as it
 has no special semantics as of yet.
 
 In cases where specialized render objects (typically with display
 inline-block) are used  (e.g. an operator), the assert fires:
 
 a href='#'
  math xmlns='http://www.w3.org/1998/Math/MathML'mox/mo/math
 /a
 
 At this point, I don't think my code is directly causing the anchor to
 get marked
 with a child needing layout.  I do rely on RenderBlock::layout() within most
 of the rendering objects to handle the actual layout after adjustments.
 
 I've tried making sure that the parent or container schedule a re-layout but
 that hasn't really helped.
 
 You can see all these adjustments and optimizations in the patch for:
 
   https://bugs.webkit.org/show_bug.cgi?id=43462
 
 Any ideas of what to look at next would be appreciated.
 
 
 -- 
 --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] Focus Crash Relating to MathML

2010-10-19 Thread David Hyatt
On Oct 19, 2010, at 2:07 PM, Alex Milowski wrote:

 On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt hy...@apple.com wrote:
 (1) Make sure any layout methods you call do setNeedsLayout(false) at the 
 end of them.
 (2) Look for any early returns in any of your layout methods, since maybe 
 you did an early return causing the setNeedsLayout(false) to be missed.
 (3) Make sure you aren't dirtying a child for a re-layout without 
 immediately doing that re-layout, e.g., don't call setChildNeedsLayout(true, 
 false) on some child and then bail without doing a layout.
 
 While this is helpful, the current code (in the patch) follows these
 principles (except when RenderBlock::layout() is called last and so
 setNeedsLayout(false) is already done).  The problem I have is an
 *ancestor* is marked as having a child needing layout during the
 layout process.  When then MathML layout finishes, the MathML
 rendering objects do not need layout but the parent is marked with
 m_normalChildNeedsLayout set to true.
 

Ok, just speculating from eyeballing the code  I think layoutInlineChildren 
should do setNeedsLayout(false) on inlines when the end of the inline is 
encountered rather than the start of it.

The iteration order is start of inline - contents of inline - end of inline, 
and we do setNeedsLayout(false) at the start of the inline.  If the contents of 
the inline end up causing a dirtying up the chain, then this will not be caught 
and cleared.

else if (o-isText() || (o-isRenderInline()  !endOfInline)) {
if (fullLayout || o-selfNeedsLayout())
dirtyLineBoxesForRenderer(o, fullLayout);
o-setNeedsLayout(false);
if (!o-isText())
toRenderInline(o)-invalidateVerticalPosition(); // FIXME: 
Should do better here and not always invalidate everything.
}

In that code above I think !endOfInline should maybe just become endOfInline 
instead.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Focus Crash Relating to MathML

2010-10-19 Thread David Hyatt
Also, if your pattern of code in a layout method is

(1) Call base class RenderBlock::layout
(2) Do other stuff that might cause dirtying

Then you should really bulletproof that code by adding

(1) Call base class RenderBlock::layout
(2) Do a setChildNeedsLayout(true, false) on yourself just to make yourself 
already dirty.
(3) Do other stuff that might cause dirtying
(4) Do a setNeedsLayout(false)

We don't really have a good setup for calling base class layout methods... 
technically you should stay dirty throughout the lifetime of your own layout 
method, but the base class method will mark you as clean.  We should come up 
with something better at some point, but for now I think if you just dirty for 
the rest of the code you want to run and then mark yourself clean at the end, 
you'd stop the problem as well.

dave

On Oct 19, 2010, at 2:07 PM, Alex Milowski wrote:

 On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt hy...@apple.com wrote:
 (1) Make sure any layout methods you call do setNeedsLayout(false) at the 
 end of them.
 (2) Look for any early returns in any of your layout methods, since maybe 
 you did an early return causing the setNeedsLayout(false) to be missed.
 (3) Make sure you aren't dirtying a child for a re-layout without 
 immediately doing that re-layout, e.g., don't call setChildNeedsLayout(true, 
 false) on some child and then bail without doing a layout.
 
 While this is helpful, the current code (in the patch) follows these
 principles (except when RenderBlock::layout() is called last and so
 setNeedsLayout(false) is already done).  The problem I have is an
 *ancestor* is marked as having a child needing layout during the
 layout process.  When then MathML layout finishes, the MathML
 rendering objects do not need layout but the parent is marked with
 m_normalChildNeedsLayout set to true.
 
 This only becomes a problem when the parent of the RenderMathMLMath
 rendering object is a RenderInline instance as the a RenderBlock will
 call setNeedsLayout(false) on itself at the very end of layout.  To
 me, although I have yet to confirm this, it seems like
 setNeedsLayout(false) is called during the layout of the inline flow
 from RenderBlock::layoutInlineChildren() on the RenderInline instance
 and then the RenderInline is marked with a child needing layout.
 Unfortunately, none of the above suggestions are going to fix that.
 
 I think the call to destroyLeftoverChildren() is also something we
 should reconsider.  In my very simple example, this is what is causing
 the RenderInline instance to be marked with a child needing layout as
 it causes a traversal through the ancestors.  I know why it is there
 but it doesn't necessarily seem like the right way (or place) to
 reorganize the operator stacking.
 
 -- 
 --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] Selection Highlight and MathML

2010-10-15 Thread David Hyatt
Do the objects actually overlap each other?

dave

On Oct 14, 2010, at 8:58 PM, Alex Milowski wrote:

 On Thu, Oct 14, 2010 at 5:19 PM, Darin Adler da...@apple.com wrote:
 On Oct 14, 2010, at 2:12 PM, Alex Milowski wrote:
 
 I'm curious as to why MathML seems to be treated differently for selection 
 highlights.
 
 Differently from what? I’m not sure what your question is.
 
 If you try out the attachment from the bug you'll see what I mean.
 Essentially, MathML
 seems to get several overlapping highlights that get darker and darker the 
 more
 that they overlap via several layers.  As such, the content eventually
 gets washed
 out by the highlight color.
 
 I do not see this behavior for non-MathML content and that leads me to
 believe we need to something in the rendering objects for MathML.
 
 
 -- 
 --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] Ruby Text Enhancements

2010-10-05 Thread David Hyatt
On Oct 5, 2010, at 7:33 PM, Eric Mader wrote:

 
 On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:
 
 This is a tough problem.  It seems like you have to get involved in the line 
 layout code e.g., findNextLineBreak in order to really do the right thing.  
 findNextLineBreak uses an iterator that walks the objects, so it's easier to 
 tell what text came before you and what text comes after you.  You can also 
 tell whether or not that text will even fit on the line and possibly do the 
 margin hacking there.
 
 I just did a prototype that checks for a RenderRubyRun in the isReplaced() 
 code inside findNextLineBreak and calls a method on the RenderRubyRun that 
 takes the last and the next object and sets negative margins by calling 
 setMarginLeft() and setMarginRight(). I stepped through this code and it 
 computes the correct margins, but the margins don't seem to take - the ruby 
 doesn't overlap the surrounding text.
 
 Guessing that some other code is resetting the margins, I modified the code 
 to cache the computed margins in the RenderRubyRun object and return the 
 cached values through subclassed marginLeft() and marginRight() methods. With 
 this change, the ruby displays as I would expect.

It's probably RenderBlockLineLayout line 348 getting you in trouble 
(computeInlineDirectionPositionsForLine).  computeLogicalWidth is called again, 
and that will recompute the left/right margins and blow away the changes you 
made to them.  I have no idea why that call is there.  It should not be 
necessary, but maybe there's something subtle I'm missing.  You could try 
removing it, and see if that fixes the problem (it should).

dave
(hy...@apple.com)



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Supporting css ime-mode property

2010-10-04 Thread David Hyatt
On Oct 4, 2010, at 10:49 PM, Simon Fraser wrote:

 On Oct 4, 2010, at 6:59 PM, Kenichi Ishibashi wrote:
 
 I'd like to implement CSS ime-mode property, which
 activates/deactivates input methods, to WebKit. Here is the MDC's
 document about this property:
 
 https://developer.mozilla.org/en/CSS/ime-mode
 
 This property is not a part of any public standard, but both of IE and
 Firefox support this property. Like Safari and Chrome, they are widely
 used browsers so the ime-mode property is frequently used when one
 wants to control input methods. So, if WebKit supports this property,
 it would improve compatibility of web pages and make web developers
 easier to implement their pages and services.
 
 I recently posted a patch to support the ime-mode property for mac
 (See https://bugs.webkit.org/show_bug.cgi?id=21279), but alexey asked
 me to discuss at WHATWG mailing list whether we really should
 implement this property. Before going to WATWG, I'd like to ask
 opinions from webkit-dev mailing list.
 
 CSS properties should be discussed on www-style, not what-wg.

If it helps with WinIE compatibility, I have no real objection to adding the 
property.  I do find it unfortunate that Microsoft implemented this feature as 
a CSS property though.   I think it should have been done as an extension to 
HTML instead.  Turning off CSS shouldn't break the author's IME intent.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Ruby Text Enhancements

2010-09-28 Thread David Hyatt
On Sep 27, 2010, at 3:40 PM, Eric Mader wrote:

 
 Are you saying that subclassing computeLogicalWidth() would still mean that 
 I'm computing the margins at the initial calculation time?
 

You'd be computing them whenever the ruby run's layout changed.  The problem 
with that is if you're setting margins based off surrounding content, you're 
not going to get a layout just because your surroundings changed.

 It just doesn't seem like you can deal with all the corner cases without 
 integrating right into line layout.  I don't see how else you can know if 
 you have adequate available space to actually overhang without knowing what 
 you've seen so far on the line and how much space you have left on the line.
 
 This would require special-casing the ruby blocks in line layout code, right? 
 I was trying to avoid this, hoping that I could just extend the existing ruby 
 objects.
 

Right.  It's kind of a minor miracle that Ruby has gotten this far without 
having to do this though. :)

 This method makes several assumptions that I'm not 100% sure are always 
 safe:
 * That a RenderRuby object holds only 1 RenderRubyRun object.
 
 I believe you can have multiple RenderRubyRuns inside a single RenderRuby.
 
 http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element
 
 The ruby element allows one or more spans of phrasing content to be marked 
 with ruby annotations.
 
 * That the text for the ruby text and ruby base are always the direct 
 child of the RenderRubyText and RenderRubyBase object.
 
 I doubt that's a valid assumption.  I assume that you can have a content 
 tree of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if 
 you put in some i and some b.  Anyway, I think you could just ask for 
 the width() of the rubyText() and rubyBase() objects themselves rather than 
 drilling down into their subtrees.
 
 I couldn't figure out how to ask the RenderRubyText and RenderRubyRun objects 
 for their width. They don't support the width() method. What method should I 
 call?
 

They should.  They are RenderBlocks, so they should have width() methods.  You 
may have just been getting bad results because you hooked in before the width 
was computed.  That's why computeLogicalWidth subclassing would work better for 
you.  Let the base class set up the margins and width, and then you override.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Fwd: Ruby Text Enhancements

2010-09-25 Thread David Hyatt
On Sep 24, 2010, at 6:56 PM, Eric Mader wrote:

 I have prototyped something that seems to more-or-less work. Here's what I 
 did:
 
 1) Changed RenderRubyRun to subclass these methods:
 virtual int marginTop() const;
 virtual int marginBottom() const;
 virtual int marginLeft() const;
 virtual int marginRight() const;
 
 
 2) added these members to RenderRubyRun:
 mutable bool m_haveHorizontalMargins;
 mutable int m_leftMargin;
 mutable int m_rightMargin;
 
 3) Added this private method to  RenderRubyRun:
 void getHorizontalMargins() const;
 
 4) Here's what marginLeft() and MarginRight() look like:
 int RenderRubyRun::marginLeft() const
 {
 getHorizontalMargins();
 
 return m_leftMargin;
 }
 
 int RenderRubyRun::marginRight() const
 {
 getHorizontalMargins();
 
 return m_rightMargin;
 }
 
 And here's getHorizontalMargins():
 void RenderRubyRun::getHorizontalMargins() const
 {
 if (m_haveHorizontalMargins) {
 return;
 }
 
 RenderText* rubyRenderText = static_castRenderText* 
 (rubyText()-firstChild());
 RenderText* baseRenderText = static_castRenderText* 
 (rubyBase()-firstChild());
 int rubyLength = rubyRenderText-firstTextBox()-width();
 int baseLength = baseRenderText-firstTextBox()-width();
 int leftMargin = RenderBlock::marginLeft();
 int rightMargin = RenderBlock::marginRight();
 
 if (baseLength  rubyLength) {
 RenderObject* prevSibling = parent()-previousSibling();
 RenderObject* nextSibling = parent()-nextSibling();
 bool prevIsText = prevSibling  prevSibling-isText();
 bool nextIsText = nextSibling  nextSibling-isText();
 
 // FIXME: handle odd difference?
 if (prevIsText)
 leftMargin += (baseLength - rubyLength) / 2;
 
 if (nextIsText)
 rightMargin += (baseLength - rubyLength) / 2;
 }
 
 m_leftMargin = leftMargin;
 m_rightMargin = rightMargin;
 m_haveHorizontalMargins = true;
 
 }
 

It would probably be simpler to just subclass computeLogicalWidth (recently 
renamed from calcWidth) and modify the m_marginLeft and m_marginRight variables 
after calling the base class method.  Then you don't have to add any new member 
variables.

The big problem with building the overhang into margins at the initial 
calculation time, though, is that you may not get a relayout when objects 
around you change, so you won't get an opportunity to adjust your margins when 
that happens.  Your margins are also computed before you've even know what's 
going on the line, so it could be really tricky to have all the information you 
need.

It just doesn't seem like you can deal with all the corner cases without 
integrating right into line layout.  I don't see how else you can know if you 
have adequate available space to actually overhang without knowing what you've 
seen so far on the line and how much space you have left on the line.


 This method makes several assumptions that I'm not 100% sure are always safe:
 * That a RenderRuby object holds only 1 RenderRubyRun object.

I believe you can have multiple RenderRubyRuns inside a single RenderRuby.

http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element

The ruby element allows one or more spans of phrasing content to be marked 
with ruby annotations.

 * That the text for the ruby text and ruby base are always the direct child 
 of the RenderRubyText and RenderRubyBase object.

I doubt that's a valid assumption.  I assume that you can have a content tree 
of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if you put in 
some i and some b.  Anyway, I think you could just ask for the width() of 
the rubyText() and rubyBase() objects themselves rather than drilling down into 
their subtrees.

 * That the neighboring text is always a direct sibling of the RenderRuby 
 object.
 

Not a valid assumption.  You could have empty spans etc.

 One enhancement I know is needed is to look at successive neighboring 
 objects to make sure that there's enough text there that the overhanging 
 part of the ruby text doesn't overshoot the neighbor(s) as well and bump 
 into something it can't overlap.
 
 Does this general approach look right?

This is a tough problem.  It seems like you have to get involved in the line 
layout code e.g., findNextLineBreak in order to really do the right thing.  
findNextLineBreak uses an iterator that walks the objects, so it's easier to 
tell what text came before you and what text comes after you.  You can also 
tell whether or not that text will even fit on the line and possibly do the 
margin hacking there.

You may not want to overhang either if the surrounding text has a higher 
ascent, since I assume you don't want to have the ruby overlapping some taller 
adjacent text.

dave
(hy...@apple.com)



___
webkit-dev mailing 

Re: [webkit-dev] Ruby Text Enhancements

2010-09-21 Thread David Hyatt

On Sep 21, 2010, at 2:52 AM, Roland Steiner wrote:

 
 
 
 We'd probably need to add a new value to that property if Ruby is supposed to 
 be skipped.
 
 Ergh Looking at it, I'm not sure that's a good proposal at all - at least 
 it has still lots to address (it doesn't address list bullets, or 
 :before/:after generated content, for one). I think that the best approach 
 for ruby would be to view the whole ruby run (i.e., base and text combined) 
 as the main object for text-decoration, and not the base and text 
 individually. That is:
 
 .) underline: line painted below the base only, over the width of base and 
 text (but excluding any overhangs!)
 .) overline: overline painted above the text, same as above - note that the 
 line width doesn't (!) change
 .) line-through: either just the base is decorated, or both base and text. I 
 can see arguments for either way, although I think painting a line-through 
 through the text may overly obscure it, since it's quite small - note that 
 the line width for the ruby text would need to be different in this case as 
 well, which in turn probably means amending the spec.
 .) blink: all blinks ;)
 
 This however means that a rule for rt would need to affect the ruby text 
 separately, independent of the decoration of the whole thing (which IMHO 
 would be a good thing anyway).

Yeah the main point I was trying to make with text-decoration is that in the 
strict mode model it's the element with text-decoration on it that draws the 
line.  So right now if you have:

a[some ruby] /a

It's the line boxes for the a element that draw a line, and it just cuts 
through the ruby no matter where the ruby happens to be (just as it might cut 
through any other objects like images that might have a different vertical 
alignment).  We have no concept of making that line skip elements or do 
something different, so it's a fair bit of work to customize the behavior.

Even more annoying is that text-decoration has two completely different code 
paths for quirks vs. strict mode.  In quirks mode, the underlines are drawn by 
the elements themselves (so e.g., you get no underlines under images in quirks 
mode), and so customizing the line drawing behavior will be easier to do in 
quirks mode.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Ruby Text Enhancements

2010-09-20 Thread David Hyatt
On Sep 17, 2010, at 8:07 PM, Eric Mader wrote:

 Hi,
 
 I'm working on making the following enhancements to Ruby Text:
 
 1) Implement the behavior of ruby-overhang:auto
 
 2) implement the behavior of ruby-line-stacking:exclude-ruby
 
 3) Add some Mac OS specific character properties to the ruby text
 
 4) Turn off the underline when the ruby text is in a link
 
 I've looked at the code enough to know that the layout or ruby text is done 
 by the normal block stacking in BlockLayout. I'm guessing that I can do at 
 lest the first two tasks by changing the RenderRuby code to report a 
 different width and / or height for the ruby block. Does this seem like the 
 right way to do what I want?
 
 Assuming for the moment that it is, I have some questions:
 
 1) What methods should I subclass to report the adjusted width and height?
 

I'm very hazy on the Ruby implementation.  I believe it makes an inline-block 
with two block children vertically stacked, and then it uses text-align:center 
to center the ruby base.  If so, this behavior has to be preserved when the 
ruby text is wider than the base.

I think a reasonable way to implement overhang therefore would be with negative 
margins applied to the ruby run.  This way the correct layout of the Ruby 
object is preserved, and the surrounding text will just naturally get pushed 
inside the Ruby object to overlap it.

Basically you can compare the delta in width between the base and the text and 
then apply margins to either side of the ruby run based off how you want to 
overhang.

 2) If the ruby text is wider than the ruby base and I report the width of the 
 base as the width of the whole block will some of the ruby text get clipped, 
 or will it all still draw?
 

It would all still draw as long as you set up overflow correctly.   You can 
look for addLayoutOverflow methods.  I think you may be able to use negative 
margins for overhang though without altering your reported width.

 3) Ruby text is only allowed to overhang the base in some cases. To know when 
 it's OK, I'll need to examine the neighboring text. Can I always find the 
 neighboring text by walking the render tree?
 

This is going to be tricky. You basically want to walk the line box tree rather 
than the renderobject tree and then look at surrounding text.

 About turning off the underline if the ruby is in a link: I've looked at the 
 styles and tried adding code to change the parts that I think relate to this, 
 but haven't found anything that makes a difference. It's also occurred to me 
 that I might be able to do this by writing a rule in 
 WebKitWebCore/css/html.css, but I can't figure out exactly what the rule 
 would look like. I tried adding text-decoration: none to the ruby  rt 
 section, but that doesn't do it.
 
 (at first, I thought that is was probably overkill, but now I think that 
 turning text-decoration off for all ruby text is probably right.)

There is no way to do this.  The closest I see is:

http://dev.w3.org/csswg/css3-text/#text-decoration-skip

This is not implemented in WebKit yet.

We'd probably need to add a new value to that property if Ruby is supposed to 
be skipped.

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] attached()

2010-09-09 Thread David Hyatt
On Sep 9, 2010, at 2:00 AM, Eric Seidel wrote:

 
 Instead, we could change all elements to mark themselves (and their
 parents) as needing style recalc during insertedIntoDocument(),
 effectively attaching/lazyAttaching.


lazyAttach is poorly implemented right now, since it is relying on style 
recalculation to trigger the attachment when it should have used a new timer.  
Right now because it is latching onto the style recalc timer and tree it is 
wasting time doing recalc styles on all of the ancestors of any elements that 
need attaching.  That's just bad.

This means the normal attach() process performs better (and is presumably still 
used by the parser).

We should fix lazyAttach to use its own timer and tree walk independent of 
recalcStyle that just calls attach() instead on children that need it.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] attached()

2010-09-09 Thread David Hyatt
On Sep 9, 2010, at 12:17 PM, Eric Seidel wrote:

 
 I'm not sure what you mean.  You mean that the change in my patch to
 run the lazyAttach logic from insertedIntoDocument may cause
 additional style recalcs?  The new element needs style calculated
 regardless.  Marking an element with childNeedsStyleRecalc doesn't
 recalculate the style for that object to my knowledge.

Oh I thought lazyAttach was actually marking nodes as needing a full style 
recalc.  If it's not then I guess that's fine.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Color Management

2010-09-01 Thread David Hyatt
On Sep 1, 2010, at 9:52 AM, Igor Trindade Oliveira wrote:

 2010/9/1 Alexey Proskuryakov a...@webkit.org:
 
 01.09.2010, в 08:31, Igor Trindade Oliveira написал(а):
 
 a) use an external dependency(littlecms for example);
 
 b) write from scratch all the ICC Profile specification;
 
 What do you guys think what the best approach?
 
 
 I think that the first question to answer is why a CMS implementation is 
 needed in WebKit at all. It's normally the job of a drawing library to 
 perform the conversion behind the scenes.
 
 For example, one can specify a color space when drawing with CoreGraphics 
 (as used by Mac and Windows Safari). If some platforms don't have such 
 support, deciding what to do with colors should be left to platform-specific 
 code in WebKit anyway.
 
 This is what already happens with images that have color profiles embedded, 
 for example.
 
 - WBR, Alexey Proskuryakov
 
 
 
 Hi,
 
 in Qt and Cairo Graphics side does not exist internally any color
 management system normally the application that needs it uses a
 external dependency like littlecms, this approach is used by Krita[1]
 for example. So if the graphics api does not have any support to color
 management the fallback could be done to WebKit CMS.
 
 Other use case could be used by icc support in css3. In the last
 draft, css3 drops color-profile property due to a lack of
 implementation [2][3].


It seems like this support would just be behind the GraphicsContext abstraction 
(which is already colorspace-aware).  I don't see why you'd need code above 
GraphicsContext.  Even color-profile in CSS should ultimately just pass the 
contents of the color profile to GraphicsContext.

For example CoreGraphics supports CGColorSpaceCreateWithICCProfile, so I'd just 
expect GraphicsContext to take the ICC profile data and let the platform decide 
what to do with it.

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Arena is crufty?

2010-09-01 Thread David Hyatt
We should just kill Arena and remove it and RenderArena both.

dave

On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:

 
 Ken's PODRedBlackTree patch has made me go back and take a closer look at 
 WebKit's Arena class. Turns out it's not a class at all, just some structs 
 and macros. That seems very un-WebKit-like to me. Ken's patch also has a 
 PODArena class, which uses Arena in its implementation. Sam suggests that 
 PODRedBlackTree should really go into WTF, which means PODArena and Arena 
 would need to go there as well.
 
 It seems like Arena really needs to be brought into the 21st century and made 
 a proper class. Maybe now is the right time to:
 
 1) Make Arena a class
 
 2) Integrate Ken's PODArena functionality into this new Arena class (or maybe 
 just make Ken's PODArena the new Arena class).
 
 3) Move the new Arena class to WTF
 
 4) Put PODRedBlackTree in WTF
 
 It looks like RenderArena is currently the only client of Arena.h, so this 
 change shouldn't be too hard. Of course, looking at RenderArena, it's a 
 little odd, too. It is not renderer specific at all. It's just an Arena that 
 recycles freed objects. Maybe we should move that functionality into the new 
 Arena class. But RenderArena is used all over the place, so maybe that's 
 going one step too far down this road?
 
 -
 ~Chris
 cmar...@apple.com
 
 
 
 
 ___
 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] Arena is crufty?

2010-09-01 Thread David Hyatt
On Sep 1, 2010, at 7:07 PM, Maciej Stachowiak wrote:

 
 On Sep 1, 2010, at 7:04 PM, David Hyatt wrote:
 
 We should just kill Arena and remove it and RenderArena both.
 
 Wasn't it still a measurable slowdown last time we tried that?
 

Not enough to matter.  We could easily make up the difference.

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Arena is crufty?

2010-09-01 Thread David Hyatt
Please let's not add another client of Arena though.  That will just make it 
harder to remove, and I highly doubt you're getting any real performance gain 
from using it.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Complex and Vector3 classes in WTF?

2010-08-31 Thread David Hyatt
On Aug 31, 2010, at 10:36 AM, Chris Marrin wrote:

 Or should we get rid of Vector3, added the functionality it needs to 
 FloatPoint3D and use that? Ken Russell already has plans to do add the 
 functions to FloatPoint3D, so I would vote for that. 

I would vote for this.  I don't think the geometry classes should move to wtf.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] What is XBL?

2010-08-25 Thread David Hyatt
The code can be removed.

dave

On Aug 25, 2010, at 12:17 PM, Adam Barth wrote:

 There seem to be a bunch of files missing too.  For example, I can't
 find XBLDocument or XMLBindingsManager.
 
 I don't mean to hate on XBL, I just started looking at it when
 deploying adoptPtr and was surprised by what I found, that's all.
 
 Adam
 
 
 On Wed, Aug 25, 2010 at 10:13 AM, Darin Adler da...@apple.com wrote:
 I think Hyatt should comment on this before we decide. I do think that 
 removing the code would be good but he may have some additional insight.
 
-- 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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Can someone explain tx/ty?

2010-08-23 Thread David Hyatt
On Aug 23, 2010, at 4:33 AM, Maciej Stachowiak wrote:

 
 
 - tx, ty are the origin of the parent's coordinate system relative to the 
 origin for its layer. When a layer paints, it establishes a CTM such that its 
 own origin is 0, 0 (I think).
 

They are relative to a painting root, which will basically either be the 
document or a compositing layer.

 The more obvious way, given the variable names, would be to make x(), y() an 
 IntPoint, with a name like originInParentCoordinates()

It already is an IntPoint internally.  There's already a method to access it as 
a point.

IntPoint location() const

 (hopefully less verbose, but you get the idea). tx, ty could be named 
 parentOffsetFromLayerCoordinates or something. This seems to be the intent of 
 the names - that x,y is a point and tx, ty is a translation. But this doesn't 
 work in point/size logic. You repeatedly add x(), y() to tx, ty to get a new 
 tx, ty. But that means you're adding a point to a size and expecting to get a 
 new size - but that's not how it works.
 

I think a helper method that does the right thing solves this problem (rather 
than having to flip what x/y and tx/ty mean just to do some math operation).

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Can someone explain tx/ty?

2010-08-23 Thread David Hyatt

On Aug 23, 2010, at 12:11 PM, David Hyatt wrote:

 
 (hopefully less verbose, but you get the idea). tx, ty could be named 
 parentOffsetFromLayerCoordinates or something. This seems to be the intent 
 of the names - that x,y is a point and tx, ty is a translation. But this 
 doesn't work in point/size logic. You repeatedly add x(), y() to tx, ty to 
 get a new tx, ty. But that means you're adding a point to a size and 
 expecting to get a new size - but that's not how it works.
 
 
 I think a helper method that does the right thing solves this problem (rather 
 than having to flip what x/y and tx/ty mean just to do some math operation).
 
 dave

Just to clarify, if tx/ty turned into an IntSize offset, I think you could just 
add a helper method like .asOffset() to IntPoint to solve this particular 
problem.

Instead of 

tx += x();
ty += y();

You could write:

offset += location().asOffset();

I'd also have no objection to just building that right into RenderBox...

offset += locationOffset();

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] ANGLE

2010-08-16 Thread David Hyatt
On Aug 14, 2010, at 10:26 PM, Darin Fisher wrote:

 On Sat, Aug 14, 2010 at 4:21 PM, k...@inf.u-szeged.hu wrote:
 
  On Aug 13, 2010, at 4:25 AM, Zoltan Herczeg wrote:
 
  Hi,
 
  ANGLE looks like a graphics helper library. Why it is placed in the root
  WebKit directory? Perhaps WebCore/platform/graphics or some kind of
  /3rparty directory would be better, wouldn't it?
 
  ANGLE is a library from Google (http://code.google.com/p/angleproject/)
  which is mirrored in the WebKit tree for convenience. Since it's not
  actually part of WebKit, it was felt that keeping it the root was best.
 
 
 /3rdparty/ANGLE would be more straightforward in my opinion. Having this
 in the root is deceptive, personally I did not realized that it is a
 mirrored tree before your explantation.
 
 
 I'm surprised it isn't pulled as a .zip like the other third-party libraries 
 (like icu, libxml, etc.) through the update-webkit script.

Agreed.  This is how I'd expect it to work.  I don't understand why it's 
checked into WebKit.  Now we're even building it as part of the build process, 
which I just don't understand.  Are we having to alter the ANGLE source in the  
WebKit tree?  That's the only reason I can think of why we would have a copy of 
the source checked in like this.

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Canvas performance and memory usage

2010-08-16 Thread David Hyatt
The changes to ImageBuffer have landed.  Here is what port authors need to know:

Image* image() on ImageBuffer is gone.

It has been replaced with:

PassRefPtrImage copyImage()

This function should always simply copy the image.   It is used in any place 
where you want to get a snapshot of the ImageBuffer and not be broken if the 
ImageBuffer subsequently changes.

For drawing, callers should now use drawImageBuffer on GraphicsContext instead 
of drawImage.  drawImageBuffer internally just turns around and calls a draw 
function on ImageBuffer.  clipToImageBuffer now also turns around and calls 
clip on the ImageBuffer.

void clip(GraphicsContext*, const FloatRect) const;

// The draw method draws the contents of the buffer without copying it.
void draw(GraphicsContext*, ColorSpace styleColorSpace, const 
FloatRect destRect, const FloatRect srcRect = FloatRect(0, 0, -1, -1),
 CompositeOperator = CompositeSourceOver, bool 
useLowQualityScale = false);
void drawPattern(GraphicsContext*, const FloatRect srcRect, const 
AffineTransform patternTransform,
 const FloatPoint phase, ColorSpace styleColorSpace, 
CompositeOperator, const FloatRect destRect);

I've made sure the above functions are implemented in the various ports, 
although the Skia and Cairo implementations currently draw by copying the image 
and then just calling drawImage.  I've left it up to those ports to fix this 
issue (the current behavior is the same on those platforms as it was before my 
patch).

There is a temporary method implemented by all ports called:

bool drawsUsingCopy() const; // If the image buffer has to 
render using a copied image, it will return true.

This method only exists right now because some of the ports are still copying.  
Once everyone has switched over to drawing the image buffer without making 
copies, then I can remove this method from the interface.  HTMLCanvasElement is 
using it in order to cache a copy of the image for repeated drawing of a static 
canvas, so that the copying platforms don't suffer a performance degradation 
from my changes.

Feel free to ping me on IRC or in email if you have any questions about this 
change.

Thanks,
Dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Canvas performance and memory usage

2010-08-11 Thread David Hyatt
Yeah I'll get it posted soon in a bug.  I need to make get/PutImageData work 
first. :)

dave

On Aug 11, 2010, at 12:35 PM, Ariya Hidayat wrote:

 http://themaninblue.com/experiment/AnimationBenchmark/canvas/
 
 Jumped from 37fps to 85fps.
 
 Do you post the patch somewhere? Would be lovely to try this on QtWebKit...
 
 
 
 -- 
 Ariya Hidayat
 http://www.linkedin.com/in/ariyahidayat
 ___
 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] Canvas performance and memory usage

2010-08-10 Thread David Hyatt
On Aug 10, 2010, at 2:38 PM, Stephen White wrote:

 On Mon, Aug 9, 2010 at 6:17 PM, David Hyatt hy...@apple.com wrote:
 There are other cases as well where you want a copy.  Patterns are another 
 example. For example you can create a pattern from another canvas, and I 
 don't think it's supposed to be live if that other canvas later changes.  
 There are examples in SVG as well where patterns are used and I am pretty 
 sure a copy is the desired behavior.
 
 I don't think it's as simple as saying image() should never copy.
 
 I spent some time thinking about this from a CG perspective, and I couldn't 
 really come up with a good solution.  We use a bitmap context for efficient 
 pixel access for get/putImageData.  Any platform that wants these functions 
 to be efficient has to keep the pixels easily obtainable.  This means, for 
 example, that we can't produce a live image using CGLayers.  Looking at Qt, 
 the only current platform to return a live image to canvas for rendering, 
 it looks like they made this tradeoff, i.e., it looks to me like 
 get/putImageData are slower than other platforms.  (The get is having to call 
 toImage() on a pixmap and then has to convert to obtain a good representation 
 of the data for a QImage).  The put has to render the changes into the pixmap.
 
 I tried renaming the two methods (image() and imageForRendering()) to 
 copiedImage and liveImage, and ended up with about an 80/20 split at the call 
 sites between the two.  It looked really ugly to me, since in nearly every 
 case the liveImage was just being used to paint the current contents of the 
 ImageBuffer, i.e., it was just being passed to drawImage.  The copiedImage 
 was typically passed to somebody who needed to retain it for later rendering, 
 e.g., a pattern.
 
 So to sum up, the call sites want two things:
 
 (1) To render the current contents of the image buffer efficiently.
 
 Would it make sense to add a GraphicsContext::drawImageBuffer(ImageBuffer*, 
 ...) call for this use case?  Then the details of how the image is actually 
 extracted (or not) could be kept down in the platform-specific layers.  I 
 don't know if this entirely helps the problem under discussion, but I ran 
 into it in another context and it seemed like it would be useful.

Yeah, I think an even better way of abstracting it might be to make 
ImageBuffer:drawIntoContext(GraphicsContext*, ...).  I think that would be 
simpler for people implementing something special.  If we did that, then the 
image() accessor on ImageBuffer could probably just always be a deep copy (or 
copy-on-write).

Getting rid of the graphicsContext-drawImage(imageBuffer-image()) pattern 
would definitely be good though.

I'm just really curious about the performance of canvas and whether it's better 
to have slower get/PutImageData or faster rendering otherwise.   It all comes 
down to how people are using canvas.  I suspect that get/PutImageData are 
really really popular.

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Canvas performance and memory usage

2010-08-10 Thread David Hyatt
On Aug 10, 2010, at 2:49 PM, David Hyatt wrote:

 Yeah, I think an even better way of abstracting it might be to make 
 ImageBuffer:drawIntoContext(GraphicsContext*, ...).  I think that would be 
 simpler for people implementing something special.  If we did that, then the 
 image() accessor on ImageBuffer could probably just always be a deep copy (or 
 copy-on-write).
 
 Getting rid of the graphicsContext-drawImage(imageBuffer-image()) 
 pattern would definitely be good though.
 
 I'm just really curious about the performance of canvas and whether it's 
 better to have slower get/PutImageData or faster rendering otherwise.   It 
 all comes down to how people are using canvas.  I suspect that 
 get/PutImageData are really really popular.

I implemented ImageBuffer::drawIntoContext on Mac, and I switched the 
implementation of ImageBuffer to dynamically swap to a CGLayer (throwing away 
the bitmap context) if it can do so.  Preliminary tests look very very good.

This benchmark for example:

http://themaninblue.com/experiment/AnimationBenchmark/canvas/

Jumped from 37fps to 85fps.

I'll need to see what happens with intensive get/PutImageData examples though 
before I declare victory, but it definitely looks like slowing down 
get/PutImageData is worth it if we can get performance gains like this!

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Canvas performance and memory usage

2010-08-09 Thread David Hyatt
There are other cases as well where you want a copy.  Patterns are another 
example. For example you can create a pattern from another canvas, and I don't 
think it's supposed to be live if that other canvas later changes.  There are 
examples in SVG as well where patterns are used and I am pretty sure a copy is 
the desired behavior.

I don't think it's as simple as saying image() should never copy.

I spent some time thinking about this from a CG perspective, and I couldn't 
really come up with a good solution.  We use a bitmap context for efficient 
pixel access for get/putImageData.  Any platform that wants these functions to 
be efficient has to keep the pixels easily obtainable.  This means, for 
example, that we can't produce a live image using CGLayers.  Looking at Qt, the 
only current platform to return a live image to canvas for rendering, it 
looks like they made this tradeoff, i.e., it looks to me like get/putImageData 
are slower than other platforms.  (The get is having to call toImage() on a 
pixmap and then has to convert to obtain a good representation of the data for 
a QImage).  The put has to render the changes into the pixmap.

I tried renaming the two methods (image() and imageForRendering()) to 
copiedImage and liveImage, and ended up with about an 80/20 split at the call 
sites between the two.  It looked really ugly to me, since in nearly every case 
the liveImage was just being used to paint the current contents of the 
ImageBuffer, i.e., it was just being passed to drawImage.  The copiedImage was 
typically passed to somebody who needed to retain it for later rendering, e.g., 
a pattern.

So to sum up, the call sites want two things:

(1) To render the current contents of the image buffer efficiently.
(2) To obtain a copied image that is independent of the image buffer that is 
typically retained by someone else.

And the current implementations of image()/imageForRendering() do three things:

(1) Make a copy of the image buffer into an Image (e.g., Skia).
(2) Make an Image that is a live representation of the Image buffer contents 
(e.g., Qt using imageForRendering).
(3) Make a copy-on-write image wrapper (e.g., CG).

Assuming the copy-on-write stuff in CG is actually working (and I suspect that 
it is), then it's actually a pretty good solution.  You don't copy to do 
throwaway drawing.  Pixel access is efficient using get/PutImageData.  There's 
no need to distinguish between copied images vs. live, with the caveat that the 
cached image has to be cleared (only an issue for canvas, since nobody else 
does continual drawing to ImageBuffers).

Anyway I'm open to suggestions here. :)

As for removing the ImageBuffer completely, I don't think you can get away with 
that.  The canvas buffer's size does not necessarily match the size into which 
it is drawn.  You need to be able to get to the image pixels of a possibly 
larger (or smaller) buffer.  You also have to be able to draw the contents of 
one canvas into another canvas, so you have to be able to treat the canvas as 
an image.  Again that means being able to get to the contents of the canvas 
itself as a separate buffer/image.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Canvas performance and memory usage

2010-08-04 Thread David Hyatt
I'm confused why a special method is needed though.  Can't image() just avoid 
the full copy?  Given how we use image() in WebKit, I don't think there's any 
reason to be concerned if image() continues to reflect the contents of the 
ImageBuffer.  I think we should just switch to that model for the CG port also 
anyway, since I'm unconvinced we're truly avoiding a copy, and return an image 
with a custom data provider that feeds the current contents of the ImageBuffer 
to the image.

dave
(hy...@apple.com)

On Aug 3, 2010, at 8:55 PM, Martin Robinson wrote:

 Resent from the proper address:
 
 On Tue, Aug 3, 2010 at 6:00 PM, Martin Robinson
 martin.james.robin...@gmail.com wrote:
 I notice that Qt added imageForRendering() and felt they could not use
 image() for some reason.  I'd be curious if a Qt expert could weigh in on
 that, since maybe with a redesign a separate call would not be needed.
 
 I'm not a Qt expert, but just based on a quick look, it seems that
 imageForRendering  avoids the full QPixmap copy. Christophe,
 when you open a bug for this issue,  please CC me, as I have a
 small patch in my tree which has the same imageForRendering
 pecialization, but for Cairo.
 
 Martin
 ___
 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] Canvas performance and memory usage

2010-08-03 Thread David Hyatt
This would probably have to be verified, but I believe CG uses copy-on-write 
semantics when creating an image from a bitmap context.  Therefore I suspect 
this is not a performance problem with CG just because of smarts in the 
underlying CG implementation.  Basically image() is a cheap call for CG, and 
creating/destroying images over and over when frequent drawing happens is not 
expensive.  However I'm not 100% sure about this.

I think the fact that the image has to be manually cleared from the ImageBuffer 
is part of the problem.  I think we should redesign ImageBuffer::image() so 
that every time it's called you can guarantee that you're getting an accurate 
reflection of the contents of the image buffer.

I notice that Qt added imageForRendering() and felt they could not use image() 
for some reason.  I'd be curious if a Qt expert could weigh in on that, since 
maybe with a redesign a separate call would not be needed.

Here's a basic suggestion for how to improve this:

(1) Make sure your port does a lightweight wrapping of the ImageBuffer into an 
Image and does not do a copy.  It's debatable whether this Image really even 
needs to be cached if the creation operation is really lightweight.  I think 
people copied the CG implementation I wrote where I wasn't 100% sure if I 
needed to cache or not, and that has created some of the confusion.

(2) If anyone accesses the GraphicsContext of an ImageBuffer and we do cache 
the Image, maybe just assume they're going to draw and clear out the image.

Anyway, I'd definitely file a bug.

dave
(hy...@apple.com)

On Aug 3, 2010, at 3:20 PM, Christophe Public wrote:

 Hi,
 
 There is a performance hit when using HTML canvas when using ImageBufferCairo:
 
 - As soon as something is rendered in the canvas, the 
 HTMLCanvasElement::willDraw method is called which in turn calls clearImage 
 on the imageBuffer if one is already present. 
 - When the render tree is traversed (HTMLCanvasElement::paint gets called), 
 the image containing the canvas is drawn using GraphicsContext::drawImage. 
 Unfortunately, ImageBuffer::image() (in BufferImageCairo.cpp) allocates a new 
 surface, and copies the image surface into it. When very frequent updates are 
 done in the canvas, this double buffering causes significant performance 
 degradation that worsens with large canvas sizes. In addition, the extra 
 memory consumption can become quite expensive especially on embedded devices.
 
 Can anybody explain why this double buffering is necessary for ImageBuffer 
 specifically for the Cairo port? 
 
 We are looking at disabling the double buffering at least for the canvas 
 because of both performance and memory issues. It would also be nice to 
 disable it for images as well but we would like to understand why in the 
 first place it was added. Note that a code comment states This seems silly, 
 but is the way the CG port works: image() is intended to be used only when 
 rendering is complete.
 
 Any suggestion on how to fix this issue is welcome. If it is considered a 
 bug, then I will create a bug as well to keep track of it.
 
 Regards,
 Christophe
 
 ___
 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] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread David Hyatt
On Jul 12, 2010, at 12:09 PM, Maciej Stachowiak wrote:

 
 The reason for these is historical. Originally, we didn't use a separate 
 vendor prefix for WebKit, just -khtml. Later we changed to -apple.

That's not quite right.  Originally we just had -khtml- for CSS extensions, and 
then we used -apple- for features that we were Apple-specific, i.e., that we 
knew nobody else would care about.  Those features include Dashboard regions 
and Safari RSS line clamping).  Eventually we just decided to merge both into a 
common prefix, but we wanted to keep the old property names working for 
compatibility.   It was convenient to just map both to -webkit- rather than 
actually checking the specific property names and only supporting either 
-khtml- or -apple-.

My recommendation would be as follows:
(1) Drop support for -khtml- completely.
(2) Continue to support -apple- for -apple-dashboard-region and 
-apple-line-clamp only.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)

2010-06-17 Thread David Hyatt
On Jun 17, 2010, at 2:45 PM, Gustavo Sverzut Barbieri wrote:

 David, it's bit more than annoying, it's fragmenting memory for no
 good. In the long run on systems will small memory it does make a
 difference :-/
 
 I'd like to see some option, maybe compile-time, to strip these
 useless whitespaces.
 

As Alexey points out, this is a compatibility issue though.  People write code 
assuming the whitespace nodes are there.  If you remove them, you'll see Web 
site breakage.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)

2010-06-17 Thread David Hyatt
On Jun 17, 2010, at 4:07 PM, Eric Seidel wrote:

 A does not follow from B in that sentence, that current memory
 fragmentation means we need to strip whitespace nodes.
 

Yeah exactly.  Let's see some measurements that show the presence of these 
nodes are a real problem.

 It would also be possible to create a special shared \n text node,
 and have some sort of Copy On Write behavior.  Again, more complexity.
 Not sure if the complexity would be worth the perf win.
 

There might be interesting tricks around this idea yeah.  Basically you want 
the common case of never really looking at the DOM from JS to result in 
efficient performance/memory use.  If walking the DOM then results in the 
creation of a more heavyweight whitespace Node, that would be fine I think.

The idea of trying to fold the information into Element is an interesting one.  
Again I think we'd need measurements to see how much of a gain we'd typically 
get if we did this just for newlines for example, or if we'd need an 
optimization that extended to arbitrary whitespace sequences.  I tend to think 
the latter would be required (since cleanly indented HTML will have newlines 
and tabs and spaces for indentation in between elements).

I'm not particularly interested in a break-the-web mode that strips out those 
Nodes completely by default, since (a) breaking compatibility is bad and (b) 
nobody has shown me any evidence that these extra nodes are a problem on mobile 
devices.

An optimization that reduces memory use while preserving the correct behavior 
is much more appealing to me.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)

2010-06-17 Thread David Hyatt
I filed https://bugs.webkit.org/show_bug.cgi?id=40800 to track  this issue.  I 
think we can take further discussion to the bug.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)

2010-06-16 Thread David Hyatt
Whitespace nodes most commonly occur between elements, so they can't be 
coalesced.

dave

On Jun 14, 2010, at 7:00 PM, Matt 'Murph' Finnicum wrote:

 Why are there so many Text nodes in the DOM? I had a look at the initial DOM 
 tree from rendering slashdot, and there are 1959 Text nodes. Of those 1959, 
 1246 were whitespace-only nodes.
 
 Does there need to be this many nodes? Why can't whitespace be combined with 
 the nodes next to it?
 
 Thanks,
 --Murph
 ___
 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] Mouse wheel event precision

2010-06-10 Thread David Hyatt
On Jun 10, 2010, at 1:01 PM, Nathan Vander Wilt wrote:

 On Jun 9, 2010, at 3:51 PM, David Hyatt wrote:
 On Jun 9, 2010, at 2:25 AM, Andy Estes wrote:
 
 
 On Jun 8, 2010, at 8:34 PM, Nathan Vander Wilt wrote:
 
 What Safari 4 seemed to do was simply provide much greater precision, 
 where scrolling half a line simply yielded about 20 units instead of being 
 ignored. So the above code would yield integral deltas in browsers that 
 only fired events in 3-line increments, but nice fractional deltas in 
 WebKit.
 
 Some sites choose to completely ignore wheel deltas less than 120.  On 
 devices like trackpads where a slow but continuous scrolling gesture tends 
 to result in a series of small, non-cumulative mousewheel events, the old 
 behavior caused these gestures to be completely ignored.  Yahoo! Mail was 
 one such site where the small fractional values caused compatibility issues.
 
 What Safari 5's WebKit does is turn one line into 4800 (!) units instead 
 of 40.
 
 This could be plausible on a trackpad that scales the wheelDelta based on 
 gesture velocity, although I'd expect a value of 120 for each tick of a 
 conventional wheel mouse.  As Peter said, if you have a test case where 
 Safari disagrees with IE on Windows or Chrome on either platform, please 
 file a bug and we'll investigate.
 
 Just a guess, but we might have a regression when dealing with the 
 continuous events generated by a MacBook trackpad.
 
 
 
 Thanks, David. I am testing this with my MacBook trackpad (and attached Magic 
 Mouse) in Safari 5.
 
 The following demo will need some massaging to work in IE, but shows the 
 problem. Scrolling down so Line 4. is at the top of the page yields a 
 deltaSum of -7200 (!). Interpreted according to MSDN documentation 
 (http://msdn.microsoft.com/en-us/library/ms536951(VS.85).aspx) this would -60 
 increments (which IIRC are 3-line chunks each) and over seven thousand 
 pixels according to Quirksmode's interpretation 
 (http://www.quirksmode.org/dom/w3c_events.html, grep wheelDelta) of that 
 property. Basically, the wheelDelta values are 60 times what they should be.
 
 On Safari 4, the deltaSum ends up at -120 as expected when scrolling down to 
 Line 4, although quite helpfully the sum can be reached gradually when the 
 mouse has smooth scrolling. So I would concur that this a regression of some 
 sort.
 
 thanks,
 -natevw

Having investigated the original bug and its fix that caused this regression,  
Safari 4's behavior was correct.  The new behavior is broken.  A tiny 
continuous event in Safari 4 correctly reported values that are smaller than 
one line delta, because that's exactly what was supposed to happen in terms of 
scrolling.

There are Web sites that depend on never scrolling less than 1 wheel delta line 
though.  So what can we do to get the best of both worlds?

Well, the compatibility fix made all of the continuous deltas way larger than 
they should be, just to ensure that you never give a value smaller than 120.  
That was not the right thing to do.

If we can't evangelize the Web sites to fix their broken checks, then a better 
fix would be to just ensure that the minimum value of a wheel event is 120, 
without performing what amounts to double multiplication of the continuous 
event.  This way we only inflate the continuous delta of the small scrolling 
gestures.

Even then, though, we lose some of the magic of continuous scrolling in that 
the small gestures aren't supposed to each result in single line movements.  My 
top preference would be to evangelize the Web sites, but I would settle for 
applying the minimum of 1 wheel line (120) to continuous events.   The current 
behavior is clearly wrong though and needs to be fixed.

dave
(hy...@apple.com)



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Mouse wheel event precision

2010-06-10 Thread David Hyatt
I filed 

https://bugs.webkit.org/show_bug.cgi?id=40441

to track this issue.

dave
(hy...@apple.com)

On Jun 10, 2010, at 2:26 PM, David Hyatt wrote:

 On Jun 10, 2010, at 1:01 PM, Nathan Vander Wilt wrote:
 
 On Jun 9, 2010, at 3:51 PM, David Hyatt wrote:
 On Jun 9, 2010, at 2:25 AM, Andy Estes wrote:
 
 
 On Jun 8, 2010, at 8:34 PM, Nathan Vander Wilt wrote:
 
 What Safari 4 seemed to do was simply provide much greater precision, 
 where scrolling half a line simply yielded about 20 units instead of 
 being ignored. So the above code would yield integral deltas in browsers 
 that only fired events in 3-line increments, but nice fractional deltas 
 in WebKit.
 
 Some sites choose to completely ignore wheel deltas less than 120.  On 
 devices like trackpads where a slow but continuous scrolling gesture tends 
 to result in a series of small, non-cumulative mousewheel events, the old 
 behavior caused these gestures to be completely ignored.  Yahoo! Mail was 
 one such site where the small fractional values caused compatibility 
 issues.
 
 What Safari 5's WebKit does is turn one line into 4800 (!) units 
 instead of 40.
 
 This could be plausible on a trackpad that scales the wheelDelta based on 
 gesture velocity, although I'd expect a value of 120 for each tick of a 
 conventional wheel mouse.  As Peter said, if you have a test case where 
 Safari disagrees with IE on Windows or Chrome on either platform, please 
 file a bug and we'll investigate.
 
 Just a guess, but we might have a regression when dealing with the 
 continuous events generated by a MacBook trackpad.
 
 
 
 Thanks, David. I am testing this with my MacBook trackpad (and attached 
 Magic Mouse) in Safari 5.
 
 The following demo will need some massaging to work in IE, but shows the 
 problem. Scrolling down so Line 4. is at the top of the page yields a 
 deltaSum of -7200 (!). Interpreted according to MSDN documentation 
 (http://msdn.microsoft.com/en-us/library/ms536951(VS.85).aspx) this would 
 -60 increments (which IIRC are 3-line chunks each) and over seven thousand 
 pixels according to Quirksmode's interpretation 
 (http://www.quirksmode.org/dom/w3c_events.html, grep wheelDelta) of that 
 property. Basically, the wheelDelta values are 60 times what they should be.
 
 On Safari 4, the deltaSum ends up at -120 as expected when scrolling down to 
 Line 4, although quite helpfully the sum can be reached gradually when the 
 mouse has smooth scrolling. So I would concur that this a regression of some 
 sort.
 
 thanks,
 -natevw
 
 Having investigated the original bug and its fix that caused this regression, 
  Safari 4's behavior was correct.  The new behavior is broken.  A tiny 
 continuous event in Safari 4 correctly reported values that are smaller than 
 one line delta, because that's exactly what was supposed to happen in terms 
 of scrolling.
 
 There are Web sites that depend on never scrolling less than 1 wheel delta 
 line though.  So what can we do to get the best of both worlds?
 
 Well, the compatibility fix made all of the continuous deltas way larger than 
 they should be, just to ensure that you never give a value smaller than 120.  
 That was not the right thing to do.
 
 If we can't evangelize the Web sites to fix their broken checks, then a 
 better fix would be to just ensure that the minimum value of a wheel event is 
 120, without performing what amounts to double multiplication of the 
 continuous event.  This way we only inflate the continuous delta of the small 
 scrolling gestures.
 
 Even then, though, we lose some of the magic of continuous scrolling in that 
 the small gestures aren't supposed to each result in single line movements.  
 My top preference would be to evangelize the Web sites, but I would settle 
 for applying the minimum of 1 wheel line (120) to continuous events.   The 
 current behavior is clearly wrong though and needs to be fixed.
 
 dave
 (hy...@apple.com)
 
 
 
 ___
 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] Mouse wheel event precision

2010-06-10 Thread David Hyatt
I think for now I'm just going to implement the minimum line movement of 1 
and only do it at the DOM event level.  That way if we use the wheel event 
internally (e.g., for a non-native scrollview implementation) it will still do 
the right thing.

dave

On Jun 10, 2010, at 3:01 PM, Peter Kasting wrote:

 On Thu, Jun 10, 2010 at 12:26 PM, David Hyatt hy...@apple.com wrote:
 There are Web sites that depend on never scrolling less than 1 wheel delta 
 line though.  So what can we do to get the best of both worlds?
 
 Can we keep a count of the total delta not yet sent to the page, and each 
 time it overflows one wheel delta, send the number of whole wheel deltas and 
 decrement the counter?  Or is that what you were suggesting?
 
 Unfortunately I don't see how we can simultaneously do this and yet still 
 send smaller deltas for pages that support them.  Perhaps we could split 
 scrolling handled by WebKit and events sent to script on the page and use 
 the fine-grained data in the first and the coarse data in the second?
 
 PK 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

2010-06-10 Thread David Hyatt
Yes, I got schooled on this days ago, but welcome to the party! ;)

dave

On Jun 10, 2010, at 6:00 PM, Maciej Stachowiak wrote:

 
 On Jun 2, 2010, at 1:22 PM, David Hyatt wrote:
 
 
 I really don't think hit testing needs to be modified to get what you want.  
 You can do a scattershot sampling using multiple candidate points within the 
 rect and apply whatever heuristics you want to choose a node.  I'm also not 
 convinced that we should be complicating core hit testing code in this way, 
 since I suspect this is one of those areas where mobile platforms will each 
 want to do their own slightly different thing anyway.
 
 I suspect hit testing a rect against the render tree could be done more 
 efficiently than scattershot sampling.
 
 Regards,
 Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] About fixing old layout bugs

2010-06-04 Thread David Hyatt
In fact the (really lousy) model I've employed in the past when this situation 
has arisen is that I hack the render tree dump to continue to dump the old 
rendering.  The render tree dumping code is full of hacks as a result and is 
basically lying about many things at this point.

It would be really nice to take the time to remove all of these hacks and just 
update every test, but we need a good solution for how to update many tests 
without breaking the tree.

dave

On Jun 3, 2010, at 6:16 PM, Ojan Vafai wrote:

 When there are only a couple tests that need new expectations, you can get 
 away with committing your patch with the expectations for the platforms you 
 have access to and then immediately grabbing the new expectations off the 
 buildbots.
 
 There is currently no good way to address the cases where your patch causes 
 many tests to need new results. There are ideas to make it better, but I 
 don't think anyone is actively working on them. Specifically, the EWS bots 
 could run the layout tests and give you access to the results.
 
 For now, with patches where you need to change many results and they're 
 different on different platforms, you need to either get access to that 
 platform, or get the help of someone who has access to it.
 
 Ojan
 
 
 On Wed, Jun 2, 2010 at 7:32 PM, Xianzhu Wang phnix...@gmail.com wrote:
 Hi,
 
 I'm still wondering what the best practice is to deal with many updated 
 layout tests in a patch. It seems I must run the layout tests on all effected 
 platforms by myself to ensure a green build after committing the patch, 
 right? This is really difficult to me. Is there a easier way?
 
 Thanks,
 Xianzhu
 
 2010/6/2 Xianzhu Wang phnix...@gmail.com
 
 Hi,
 
 I'm new to webkit development, and I'd like to hear opinions about the 
 problems I met.
 
 Now I'm trying to fix some old layout bugs, for example:
   * white space preceding br (https://bugs.webkit.org/show_bug.cgi?id=37261)
   * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413)
   * line breaking around some punctuations 
 (https://bugs.webkit.org/show_bug.cgi?id=37698)
 
 Some people have warned me about the difficulty of fixing these bugs, and now 
 I have realized it. Fixing the bugs themselves is not very difficult, for 
 example, only 2 functional lines change can fix the first bug. However, the 
 change will break more than 4000 existing layout tests mostly because 
 trailing spaces preceding brs in current expectations of the tests (for 
 example, PASS  vs PASS). I tried to rebaseline all effected layout tests 
 (for now on mac only), and the patch is about 6MB (Sorry I overlooked the 
 Bigfile option when I submitted the patch, so I split it into 4 parts).
 
 My questions are:
 
 1. The bugs violate the standards and cause some site compatibility issues. 
 However, because the bugs are old, some web developers might treat them as 
 features and depend on them, so fixing them might break some existing pages. 
 Is there any existing policy about this problem? Are these bugs worth fixing?
 
 2. What's the best practice to deal with a patche containing many updated 
 layout test expectations? Is there a good way to rebaseline the effected 
 tests on all platforms?
 
 Thanks,
 Xianzhu
 
 
 
 ___
 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] On adding 'console.memory' API (and about the whole 'console' object.)

2010-06-04 Thread David Hyatt
I'm fairly certain I could construct an attack on :visited history privacy 
using this object.

dave

On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote:

 On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig sam.wei...@gmail.com wrote:
 After talking it over with some folks here at Apple, I want to formally 
 object to adding the Console.memory extension to the Console object and I 
 think we should remove support for Console.profiles as soon as we can.  They 
 both provide information to users that are not generally useful (beyond the 
 continuous integration/buildbot use-case which I think is of limited 
 utility) and therefore should not be exposed to the web.
 
 Why is the continuous integration/buildbot use-case of limited utility? Or 
 are you saying that Console.memory doesn't really support that use-case well? 
 I think we want to make it as easy as possible for complex apps (e.g. email 
 apps, mapping apps, etc.) to care about and monitor memory use. 
 
 While I'm not convinced by the utility argument, I do buy the security 
 argument. How would you feel about leaving the code in, but disabling it by 
 default? Then it could be enabled by command-line or via a preference.
 
 That said, I'm OK with rolling back for now given that the code was committed 
 without this discussion actually coming to a conclusion.
 
 Ojan
 ___
 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] About fixing old layout bugs

2010-06-04 Thread David Hyatt
For this particular bug (the br one), even ref tests would be inadequate, 
since the reference renderings would have to change too.

dave

On Jun 4, 2010, at 2:17 PM, Dirk Pranke wrote:

 One admittedly painful way to do this would be to dump two render
 trees, an old format and a new format, and then build tooling to roll
 between the versions. Most of the pain would probably be in modifying
 the dump code to accept version flags and know whether to output old
 or new as necessary.
 
 Of course, you can't really do this for pixel tests, so you're still
 kind of stuck.
 
 ref tests might be a  better answer in both situations.
 
 -- Dirk
 
 On Fri, Jun 4, 2010 at 10:36 AM, David Hyatt hy...@apple.com wrote:
 In fact the (really lousy) model I've employed in the past when this
 situation has arisen is that I hack the render tree dump to continue to dump
 the old rendering.  The render tree dumping code is full of hacks as a
 result and is basically lying about many things at this point.
 It would be really nice to take the time to remove all of these hacks and
 just update every test, but we need a good solution for how to update many
 tests without breaking the tree.
 dave
 On Jun 3, 2010, at 6:16 PM, Ojan Vafai wrote:
 
 When there are only a couple tests that need new expectations, you can get
 away with committing your patch with the expectations for the platforms you
 have access to and then immediately grabbing the new expectations off the
 buildbots.
 
 There is currently no good way to address the cases where your patch causes
 many tests to need new results. There are ideas to make it better, but I
 don't think anyone is actively working on them. Specifically, the EWS bots
 could run the layout tests and give you access to the results.
 For now, with patches where you need to change many results and they're
 different on different platforms, you need to either get access to that
 platform, or get the help of someone who has access to it.
 Ojan
 
 On Wed, Jun 2, 2010 at 7:32 PM, Xianzhu Wang phnix...@gmail.com wrote:
 
 Hi,
 I'm still wondering what the best practice is to deal with many updated
 layout tests in a patch. It seems I must run the layout tests on all
 effected platforms by myself to ensure a green build after committing the
 patch, right? This is really difficult to me. Is there a easier way?
 Thanks,
 Xianzhu
 
 2010/6/2 Xianzhu Wang phnix...@gmail.com
 
 Hi,
 I'm new to webkit development, and I'd like to hear opinions about the
 problems I met.
 Now I'm trying to fix some old layout bugs, for example:
   * white space preceding br
 (https://bugs.webkit.org/show_bug.cgi?id=37261)
   * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413)
   * line breaking around some punctuations
 (https://bugs.webkit.org/show_bug.cgi?id=37698)
 Some people have warned me about the difficulty of fixing these bugs, and
 now I have realized it. Fixing the bugs themselves is not very difficult,
 for example, only 2 functional lines change can fix the first bug. However,
 the change will break more than 4000 existing layout tests mostly because
 trailing spaces preceding brs in current expectations of the tests (for
 example, PASS  vs PASS). I tried to rebaseline all effected layout 
 tests
 (for now on mac only), and the patch is about 6MB (Sorry I overlooked the
 Bigfile option when I submitted the patch, so I split it into 4 parts).
 My questions are:
 1. The bugs violate the standards and cause some site compatibility
 issues. However, because the bugs are old, some web developers might treat
 them as features and depend on them, so fixing them might break some
 existing pages. Is there any existing policy about this problem? Are these
 bugs worth fixing?
 2. What's the best practice to deal with a patche containing many updated
 layout test expectations? Is there a good way to rebaseline the effected
 tests on all platforms?
 Thanks,
 Xianzhu
 
 
 ___
 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 mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)

2010-06-04 Thread David Hyatt
To get more specific, the style allocated for visited state is freed when 
you're an unvisited link to save memory (lots of memory), but it is not freed 
if you're visited.  So there's a definite memory consumption difference.  This 
memory difference would be magnified and obvious if you made 1 visited 
links vs. 1 unvisited links.

We would have to deliberately consume megabytes more of memory just to prevent 
this attack if we keep this object in, and I just made the above fix to prevent 
a more than 4mb memory regression.

Therefore I do not think memory use information is safe to expose, and this 
feature is not something we should be adding.

dave
(hy...@apple.com)

On Jun 4, 2010, at 2:06 PM, David Hyatt wrote:

 I'm fairly certain I could construct an attack on :visited history privacy 
 using this object.
 
 dave
 
 On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote:
 
 On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig sam.wei...@gmail.com wrote:
 After talking it over with some folks here at Apple, I want to formally 
 object to adding the Console.memory extension to the Console object and I 
 think we should remove support for Console.profiles as soon as we can.  They 
 both provide information to users that are not generally useful (beyond the 
 continuous integration/buildbot use-case which I think is of limited 
 utility) and therefore should not be exposed to the web.
 
 Why is the continuous integration/buildbot use-case of limited utility? Or 
 are you saying that Console.memory doesn't really support that use-case 
 well? I think we want to make it as easy as possible for complex apps (e.g. 
 email apps, mapping apps, etc.) to care about and monitor memory use. 
 
 While I'm not convinced by the utility argument, I do buy the security 
 argument. How would you feel about leaving the code in, but disabling it by 
 default? Then it could be enabled by command-line or via a preference.
 
 That said, I'm OK with rolling back for now given that the code was 
 committed without this discussion actually coming to a conclusion.
 
 Ojan
 ___
 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] Proposal: Link http header support

2010-06-03 Thread David Hyatt
Really? I thought they did, at least for stylesheets.

dave

On Jun 3, 2010, at 8:14 AM, Gavin Peters (蓋文彼德斯) wrote:

 No, no other browsers support it.  There's a similar feature in Mozilla, the 
 LINK rel=prefetch item, but to my knowledge, Mozilla does not support the 
 Link header.
 
 On Wed, Jun 2, 2010 at 8:41 PM, Peter Kasting pkast...@google.com wrote:
 On Wed, Jun 2, 2010 at 3:28 PM, Gavin Peters (蓋文彼德斯) gav...@chromium.org 
 wrote:
 I'm starting hacking at adding support for the Link: http header.  This is 
 described in RFC 2068, although not RFC 2616.  As well, there's a current 
 internet draft describing it: 
 http://tools.ietf.org/id/draft-nottingham-http-link-header-10.html .  This 
 header is being discussed in the IETF HTTP WG mailing list.  Since it was in 
 HTTP 1.1 as first published, it is reserved, and legal to use today for this 
 purpose.
 
 Is this supported in any other browsers?  Do websites make use of it?
 
 I'm not saying you should necessarily stop if the answers are no, but it's 
 good to know the lay of the land.
 
 PK 
 
 ___
 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] Proposal: Link http header support

2010-06-03 Thread David Hyatt
On Jun 2, 2010, at 5:28 PM, Gavin Peters (蓋文彼德斯) wrote:

  I don't think I'll share much code .

Try to share as much code as you can, assuming it makes sense to do so.  We 
could always refactor common code into something like a CSSStyleSheetLoader 
class if we needed to.

dave
(hy...@apple.com)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

2010-06-02 Thread David Hyatt
On Jun 2, 2010, at 2:46 PM, Antonio Gomes (:tonikitoo) wrote:

 Hi,
 
 As most of you have experienced, the precision of a mouse click on
 Desktop applications, including Web browsers, is much higher than the
 precision of a touch tap on a mobile device. It is not a new problem,
 and many solutions have been proposed to improve that situation. One
 of the common solutions is to make a small target’s tap-sensitive area
 larger, invisibly, than the visible target itself. Of course, it would
 not work on a mobile Web browser, since it'd end up breaking the
 desired layout of any non-simple Web site.
 
 Mozilla has addressed this problem by implementing the SmartTap
 feature [1]. The solution is simple: a nodesFromRect method is
 available for applications {fennec, firefox, etc}. As the name
 implies, given a rect (corresponding to tapped area), it returns a
 list of candidate mouse clickable target nodes for the tap. This
 list is sorted by z-order, larger intersection area, most visited (in
 case of links), etc. Call sites can then pick the first element on the
 list, or use any different heuristic to choose the target.
 
 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=489127
 
 After some initial research, mostly understanding the HitTest system
 of WebCore, I am sure we can provide something similar as a cross
 platform solution for the problem.
 
 For the moment, my plan is to use better hit testing to make it easier
 for users to click  focus hyperlinks and input fields. For that, the
 HitTest system would have to be modified to receive a Rect as input,
 instead of a Point. It would also have to hold a list of possible
 target candidate nodes, instead of only a single target node as it
 does currently. In deep, the many ::nodeAtPoint implementations would
 have to be adjusted to work with a Rect, not a Point, and probably
 renamed to something similar to nodesAtRect. Much of the current
 HitTest logic in RenderLayer would not need changes, though.
 
 To keep the current mouse behavior (which is clearly point-based), we
 could just pass rects with width and height equal to 1, so a Rect(x,
 y, 1, 1) would behavior equally or very similarly to Point(x, y).
 
 Before going this way, I would like to know of any known problem or
 show stoppers.

I really don't think hit testing needs to be modified to get what you want.  
You can do a scattershot sampling using multiple candidate points within the 
rect and apply whatever heuristics you want to choose a node.  I'm also not 
convinced that we should be complicating core hit testing code in this way, 
since I suspect this is one of those areas where mobile platforms will each 
want to do their own slightly different thing anyway.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

2010-06-02 Thread David Hyatt
On Jun 2, 2010, at 3:22 PM, David Hyatt wrote:

 
 Before going this way, I would like to know of any known problem or
 show stoppers.
 
 I really don't think hit testing needs to be modified to get what you want.  
 You can do a scattershot sampling using multiple candidate points within the 
 rect and apply whatever heuristics you want to choose a node.  I'm also not 
 convinced that we should be complicating core hit testing code in this way, 
 since I suspect this is one of those areas where mobile platforms will each 
 want to do their own slightly different thing anyway.

This sounded a bit more negative than I intended.  I don't mind hit testing 
being modified in this way as long as we think we can make it truly 
cross-platform (such that everyone who wants similar functionality can use the 
code), and it would be very important to not regress the single point case.  If 
those conditions can be met, then I would be satisfied.

dave


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

2010-06-02 Thread David Hyatt
He would want 1,1.

dave

On Jun 2, 2010, at 3:58 PM, Peter Kasting wrote:

 On Wed, Jun 2, 2010 at 1:52 PM, Antonio Gomes (:tonikitoo) 
 toniki...@gmail.com wrote:
 If a port do not want to
 take advantage of the new support, the current functionality should
 and would be kept, i.e. Rect(x,y,1,1,) would do the trick.
 
 Be careful to check whether you really want 1, 1 or 0, 0 as the size in your 
 new API.
 
 PK 
 ___
 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] Webkit handling of SVG with rgba() color

2010-06-01 Thread David Hyatt
I think we should support rgba/hsla colors in SVG.

dave

On Jun 1, 2010, at 12:23 PM, Dirk Schulze wrote:

 The SVG 1.1 specification has a reference to CSS2. So from the
 specifications point of view, rgba() shouldn't be supported.
 Nevertheless SVG 1.1se won't have a strict reference to CSS2. Also other
 browsers support rgba on SVG already.
 I'm fine with a rgba implementation and Eric wrote already what is
 needed to support it on the bug report.
 
 Dirk
 
 I was looking at Bug 16183
 (https://bugs.webkit.org/show_bug.cgi?id=16183) - SVG doesn't support
 rgba() colors.  I was planning on fixing this but after reading the
 SVG spec at http://www.w3.org/TR/SVG11/ which states that SVG supports
 CSS2 color specifications I'm unsure if this should be fixed or not.
 rgba() was introduced with CSS3 so is technically not supported by
 SVG.  
 
 
 Looking at other implementations Chrome and webkit-head both render a
 rgba() color as pure black.  Safari 4.0.5 I've seen render it as
 either black or missing.  Firefox does render it properly.  Batiq
 fails to render and gives an error: The attribute stroke represents
 an invalid CSS value (rgba(0, 255, 0, 0.5)).  
 
 
 Looking at this bug from an end user perspective it would be good to
 add this feature in as its likely that people will build sites that
 aren't strictly compliant and would want things to just work.  However
 I'm always wary of making changes that go against a published standard
 as that path can lead to ugliness, divergent standards and future
 headaches.  
 
 
 What I'm looking for from the community is feedback on what the right
 thing to do here with respect to webkit is.  Is it worth the
 convenience to the user to add support for rgba() to the SVG code? 
 
 
 -Jon
 ___
 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] Table rendering and colspans

2010-05-27 Thread David Hyatt
In general our strategy for table rendering is to match whatever Internet 
Explorer does.

Try your table test cases in IE for Windows in both quirks mode (no doctype) 
and strict mode (!doctype html) and see what IE does.  Assuming IE's 
rendering makes sense, that's probably what we want to do as well.

dave

On May 27, 2010, at 2:16 PM, Fady Samuel wrote:

 Hi,
 
 I have a quick question (*crosses fingers*) about colspans in webkit. I've 
 attached a simple example, t8_simple. In this example, we have two rows. One 
 with one cell with a colspan of 5, and the other has two cells, the first 
 having a colspan of 1, and the second having a colspan of 3. Thus, we have an 
 empty slot in the in grid on the second row. In webkit, this introduces an 
 extra gap at the end of the second row corresponding to the cell spacing 
 between the second cell and the empty cell. This gap does not appear on 
 Firefox or Opera.
 
 I've found yet another inconsistency (see attached t9_simple). As you 
 increase colspan on the first cell, in webkit the gap in the second row grows 
 by a pixel or two. Firefox remains unchanged. In Opera, the whole table width 
 increases. What is the correct behavior?  
 
 I'm currently reworking chunks of the table rendering code for performance 
 reasons so it would be nice to know if these are legitimate table rendering 
 bugs that should be ironed out or the current webkit behavior is good.
 
 Thanks,
 
 Fady Samuel
 t8_simple.htmlt9_simple.html

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Table hit testing

2010-05-20 Thread David Hyatt
You can't binary search if there are overflowing cells in any section.  You 
have to go in order (from last to first) in that case, since you may hit test 
something.

In general you won't find binary searches, etc. in most hit testing code 
because of overflow concerns.

http://www.zazzle.com/css_is_awesome_mug-168716435071981928

I strongly recommend not writing code that deviates from what the paint methods 
do.  In general the nodeAtPoint version of a function should be just like the 
paint version of a function, just from last to first rather than first to last.

Any time hit testing and painting deviate, you have a problem, since the 
painting stack order and the hit testing stack order obviously need to agree.

Basically I'd expect a first patch to synchronize the two methods (paint and 
nodeAtPoint), and then if you want to optimize further, I'd expect to see 
optimizations to both painting and hit testing made together.

dave
(hy...@apple.com)

On May 20, 2010, at 10:58 AM, Fady Samuel wrote:

 So I have an implementation that seems to be working (still testing edge 
 cases). I found that m_grid, in RenderTableSection, is a VectorRowStruct 
 and each RowStruct contains a row which knows about the columns of that row.
 
 Thus this is effectively a dense 2D table of Cells. I use this for hit 
 testing. By the time nodeAtPoint has been called we've already computed the 
 dimensions and location of the rows and cells and all RenderTableCells are 
 reachable through m_grid. Thus, I do a binary search on the rows, comparing 
 their y position with the mouse's y pos to find which row to consider. 
 
 Then once a row has been picked, I do a binsearch on the columns within that 
 row, looking at the x positions, and then I pass the event to the nearest 
 cell. Of course, the actual mouse position may fall just outside of a cell 
 (it may lie over spacing between cells for example) but in that case the 
 RenderTableCell node would simply ignore the event. 
 
 I'm still doing testing (regression + perf). For cells with rowspan  1, it 
 seems that the a pointer to the Cell node is placed in each row its 
 associated with in m_grid. For cells with colspan  1, it seems that only the 
 first column that the cell occupies is not NULL...so I just linear scan back 
 to the first non NULL position if I encounter that. I suppose I could 
 optimize that further by filling all of m_grid appropriately and changing 
 code elsewhere to accommodate. 
 
 CSS transformations on tables seem to all automagically work, it seems all 
 the coordinate system transformation code all happens before we reach 
 RenderTableSection::nodeAtPoint.
 
 Does it sound like I'm missing anything important? I've just started playing 
 with the webkit source a couple of weeks ago, so I may have missed something 
 silly.
 
 Thanks,
 
 Fady
 
 On Tue, May 18, 2010 at 3:03 PM, Fady Samuel fsam...@google.com wrote:
 Ohh I see, I was confused about this line in RenderTable:
 
 1138 if (!hasOverflowClip() || overflowClipRect(tx, ty).contains(xPos, 
 yPos)) {
 
 It seems that the default case is to visit all the children as 
 hasOverflowClip() is false.
 
 Thanks for the explanation David. 
 
 I will look into optimizing hit testing to avoid visiting all children. 
 
 Thanks again,
 
 Fady
 
 
 On Tue, May 18, 2010 at 2:57 PM, David Hyatt hy...@apple.com wrote:
 
 On May 18, 2010, at 12:52 PM, Fady Samuel wrote:
  Hi all,
 
  I'm looking at table hit testing, and in all the simple test cases I've 
  tried, it seems to show that RenderTable never has the flag 
  m_hasOverflowClip set to true. What this means is that all the table's 
  children are ALWAYS checked on all mouse events. For large tables, or pages 
  with many tables, this sounds awfully taxing on the processor for no good 
  reason.
 
  See RenderTable::nodeAtPoint in 
  third_party/WebKit/WebCore/rendering/RenderTable.cpp . It seems 
  hasOverflowClip() is always false.
 
  Can we not compute a bounding box for the table on layout? Are there any 
  complications here that I should be aware of that resulted in this 
  inefficient solution?
 
 m_hasOverflowClip is about overflow:auto/scroll/hidden.  The default value 
 for overflow is visible, so that's not going to be set and isn't really 
 relevant to your problem.
 
 Both RenderTable and RenderTableSection need to have their nodeAtPoint 
 methods patched to be like their paint methods instead.  Both of those 
 methods would get much more efficient if we did that.
 
 dave
 (hy...@apple.com)
 
 
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Table hit testing

2010-05-20 Thread David Hyatt
On May 20, 2010, at 3:07 PM, David Hyatt wrote:

 If we could properly detect those degenerate cases, then you could probably 
 get away with binary search, but until we do that, I don't think you can.

Here's an example:

STYLE
TD:hover { color: green }
/STYLE 
TABLE border=1
TRTD1 TD2 TD3
TRTD4 TD rowspan=25 TD6
TRTD colspan=27 TD9
/TABLE

In this example, cell 5 and cell 7 actually overlap and share a position in the 
grid.  You can see that hit testing works properly and gives cell 7 precedence 
over cell 5 (e.g., if you're in overlapping background areas of the cell, then 
cell 7 wins).

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Table hit testing

2010-05-20 Thread David Hyatt
On May 20, 2010, at 3:52 PM, Fady Samuel wrote:

 I'm still confused about the proper ordering of painting/hit testing cells 
 for a given grid position.
 
 In the example you provided, David, WHY does cell 7 have precedence over cell 
 5? Is it based on the order they're defined? 

Yes, it's based on document order.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Table hit testing

2010-05-20 Thread David Hyatt
On May 20, 2010, at 3:38 PM, Fady Samuel wrote:

 So what are the rules for stacking here? do the cells stack in the order in 
 which they appear in the HTML?
 

Correct, although note that backgrounds paint behind foregrounds, and hit 
testing works the same way, so it's not as simple as saying that cell 7 is 
always above cell 5.  They're interleaved, so from bottom to top:

Cell 5 background
Cell 7 background
Cell 5 foreground (the number 5 in this example)
Cell 7 foreground (the number 7 in this example)

That's why if you hover over the actual number 5 in that example it will light 
up, but if you're in the background area overlap, the number 7 will light up.

http://www.w3.org/TR/CSS21/zindex.html

Therefore you do have to know about all the cells at the position, since when 
you're in the foreground phase of hit testing, cell 7 will say Nope, you're 
not inside my foreground, and so you then need to check cell 5, which will say 
Yes, you are inside my foreground.

The grid structure just isn't expressive enough.  It needs to be patched to 
track all cells in a given row/column instead of just the first one.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Table hit testing

2010-05-18 Thread David Hyatt

On May 18, 2010, at 12:52 PM, Fady Samuel wrote:
 Hi all,
 
 I'm looking at table hit testing, and in all the simple test cases I've 
 tried, it seems to show that RenderTable never has the flag m_hasOverflowClip 
 set to true. What this means is that all the table's children are ALWAYS 
 checked on all mouse events. For large tables, or pages with many tables, 
 this sounds awfully taxing on the processor for no good reason.
 
 See RenderTable::nodeAtPoint in 
 third_party/WebKit/WebCore/rendering/RenderTable.cpp . It seems 
 hasOverflowClip() is always false.
 
 Can we not compute a bounding box for the table on layout? Are there any 
 complications here that I should be aware of that resulted in this 
 inefficient solution? 

m_hasOverflowClip is about overflow:auto/scroll/hidden.  The default value for 
overflow is visible, so that's not going to be set and isn't really relevant to 
your problem.

Both RenderTable and RenderTableSection need to have their nodeAtPoint methods 
patched to be like their paint methods instead.  Both of those methods would 
get much more efficient if we did that.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Increasing the number of cross-platform/port expected results

2010-04-13 Thread David Hyatt
There are also a fair number of directories that test rendering and layout, 
although they are usually obvious by their names... many of the subdirectories 
in fast cannot be converted to pure text tests (clipping, margin collapsing, 
backgrounds, etc.).

dave

On Apr 13, 2010, at 1:54 PM, Ojan Vafai wrote:

 On Mon, Mar 1, 2010 at 7:53 PM, Maciej Stachowiak m...@apple.com wrote:
 On Mar 1, 2010, at 6:46 PM, Ojan Vafai wrote:
 On Mon, Mar 1, 2010 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote:
 On the one hand, it's good to shift the default. On the other hand, many 
 render tree dumping tests do not currently need to run any JavaScript 
 script, while many text-only tests do. I would almost suggest having a 
 per-directory default but that might be too confusing and mysterious.
 
 Yeah, I thought about having per-directory defaults too. There are some nice 
 things about that. For example, the editing tests mostly want something in 
 between dumpAsText and a render dump. It would be great if we could default 
 those to dumpAsMarkup (https://bugs.webkit.org/show_bug.cgi?id=26501).
 3 dumpAsMarkup
 
 In the webkit-meeting discussion about reducing platform-specific tests, Adam 
 brought up the idea that we could have a file that lists all the tests that 
 default to dumpAsRenderTree, move the default over to dumpAsText and then 
 gradually mark tests appropriately as dumpAsRenderTree and remove them from 
 the list.
 
 We might want to leave some directories as defaulting to dumpAsRenderTree as 
 they're tests that we imported from elsewhere (e.g. the CSS2.1 tests). We can 
 annotate the file appropriately listing just the directories. So, eventually, 
 that file will be a few lines.
 
 I think moving to just having dumpAsText be the default is better than having 
 per-directory defaults.
 
 How does that sound?
 
 Ojan
 ___
 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 can I get the Image object from the StyleImage object

2010-03-22 Thread David Hyatt
Images can either be bitmap images (GIF/JPG/PNG, etc.) or generated images that 
care about a size (gradient, SVG).  So the answer really depends on your 
purpose.  If you are just worried about bitmap images, then the passed in size 
doesn't really matter.  Otherwise the correct size to use would depend on 
context, e.g., how was it being painted (as a background, a border, a list 
bullet, etc.)

dave

On Mar 21, 2010, at 8:51 PM, hap 497 wrote:

 Hi,
 
 I would like to know how can I get the ImageObject(the one which
 passes for painting) from a StyleImage object?
 
 I am able to get the StyleImage of my element using:
 
 RenderObject *o = element-renderer();
   RenderStyle* style = o-style();
 StyleImage* bgImage = style-backgroundImage();
 
 My question is how can I get the Image being painted (the one which is
 actual pass to Graphics Context)?
 
 I see this method in StyleImage, but how can I use that? How can I
 find out the IntSize which is used for painting?
 virtual Image* image(RenderObject*, const IntSize) const = 0;
 
 Thank you for your help.
 ___
 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


  1   2   3   >