Re: [webkit-dev] Request to add Build Bot

2010-09-27 Thread Thomas Brodt

 That's good news!

Thomas


Am 24.09.2010 17:50, schrieb Brent Fulgham:

I've finally gotten a system setup and configured to run as a build
bot for the WinCairo port.  Per the instructions in the wiki, I've
filed a bug (https://bugs.webkit.org/show_bug.cgi?id=46360) to add the
configuration to the build system.

Could someone generate an ID/password combination so I could complete
the setup and try to get the bot harnessed to the build system?

Thanks!

-Brent
___
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] Fwd: Ruby Text Enhancements

2010-09-27 Thread Roland Steiner
On Sat, Sep 25, 2010 at 3:02 PM, David Hyatt hy...@apple.com wrote:

 On Sep 24, 2010, at 6:56 PM, Eric Mader wrote:

 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.


Yes - after the change for https://bugs.webkit.org/show_bug.cgi?id=41040, a
ruby run will basically contain:

[:before-generated content]? [RenderRubyRun]* [:after-generated
content]?

Where RenderRubyRun is an inline-block element with 1 RenderRubyBase and
(currently) 0-1 RenderRubyTexts - the latter may change to 0-n at some
point.

Thinking this further, I also believe that once you implement ruby overhang
for the edges of the ruby element it will really look strange unless you
also implement overhang and offsets between ruby runs within the same ruby
element - i.e., implement Jukugo-ruby. This then has implications on the
line-breaking code within a single ruby.

Finally, as yet another corner case that I forgot in my last mail: as
implied above note that you also have to consider the
:before/:after-generated content for overhang.

Incidentally, you'll also have to consider generated content for item 4) of
your initial list (over/under-lines on ruby).



Cheers,

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


Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-27 Thread Michael Nordman
Yes, if we go with telling xhr up front for the array buffer case, I guess
an enum would be slightly better.

On Fri, Sep 24, 2010 at 8:39 PM, Chris Rogers crog...@google.com wrote:

 If we added xhr.asArrayBuffer, what would happen if xhr.asBlob was also
 set?  Don't we really want something like xhr.loadAsType with different enum
 values for text, blob, array buffer, etc.?

 On Fri, Sep 24, 2010 at 5:19 PM, Michael Nordman micha...@google.comwrote:

 With xhr.responseBlob we chose to have the caller decide up front and tell
 the xhr object how it would like the response by setting the xhr.asBlob
 attribute prior to calling send(). We could do the same with
 xhr.asArrayBuffer.

 On Fri, Sep 24, 2010 at 5:09 PM, Alexey Proskuryakov a...@webkit.orgwrote:


 24.09.2010, в 16:37, Chris Rogers написал(а):

  I was interested to know if anybody was planning on implementing that
 attribute soon.  If not, I would like to add this myself.

 The key problem to solve is how to not double the memory use of the
 XMLHttpRequest object, while not making responseText and responseXML slow.

 See also: https://bugs.webkit.org/show_bug.cgi?id=40954. Do we need
 both responseBody and responseArrayBuffer?

 - WBR, Alexey Proskuryakov

 ___
 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-09-27 Thread Eric Mader
A generic question: is there any in-depth documentation I can ready about block 
layout and how the various methods are supposed to be used? I've looked at the 
technical articles at http://webkit.org/coding/technical-articles.html but they 
seem to only have fairly high-level information and left me hungry for much 
more.

Specific comments below.

Regards,
Eric

On Sep 24, 2010, at 8:02 PM, David Hyatt wrote:

 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.

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

 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.

 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?


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


Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-27 Thread Anne van Kesteren
(I'm subscribed to webkit-dev with a different address.)

On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman micha...@google.com wrote:
 Yes, if we go with telling xhr up front for the array buffer case, I guess
 an enum would be slightly better.

I do not think this should be told up front. You already need to keep
the octet buffer in memory for overrideMimeType to work the way it
does. We designed responseBlob as an optimization so you would not
have to deal with the other types. I do not think you can optimize the
reverse with the design as it stands today.

In any event, any discussion on changes to the specification really
ought to happen on public-weba...@w3.org.

Cheers,


-- 
Anne van Kesteren
http://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-27 Thread Michael Nordman
Webkit's XHR currently does not keep two copies of the data that I can see.
I think we should avoid that.

On Mon, Sep 27, 2010 at 2:40 PM, Anne van Kesteren 
annevankeste...@gmail.com wrote:

 (I'm subscribed to webkit-dev with a different address.)

 On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman micha...@google.com
 wrote:
  Yes, if we go with telling xhr up front for the array buffer case, I
 guess
  an enum would be slightly better.

 I do not think this should be told up front. You already need to keep
 the octet buffer in memory for overrideMimeType to work the way it
 does. We designed responseBlob as an optimization so you would not
 have to deal with the other types. I do not think you can optimize the
 reverse with the design as it stands today.

 In any event, any discussion on changes to the specification really
 ought to happen on public-weba...@w3.org.

 Cheers,


 --
 Anne van Kesteren
 http://annevankesteren.nl/

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


Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-27 Thread Maciej Stachowiak

On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:

 Webkit's XHR currently does not keep two copies of the data that I can see. I 
 think we should avoid that.

We could keep the raw data around, which hopefully is directly usable as an 
ArrayBuffer backing store, and only translate it to text format when/if the 
client requests responseText. 

 
 On Mon, Sep 27, 2010 at 2:40 PM, Anne van Kesteren 
 annevankeste...@gmail.com wrote:
 (I'm subscribed to webkit-dev with a different address.)
 
 On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman micha...@google.com wrote:
  Yes, if we go with telling xhr up front for the array buffer case, I guess
  an enum would be slightly better.
 
 I do not think this should be told up front. You already need to keep
 the octet buffer in memory for overrideMimeType to work the way it
 does. We designed responseBlob as an optimization so you would not
 have to deal with the other types. I do not think you can optimize the
 reverse with the design as it stands today.
 
 In any event, any discussion on changes to the specification really
 ought to happen on public-weba...@w3.org.
 
 Cheers,
 
 
 --
 Anne van Kesteren
 http://annevankesteren.nl/
 
 ___
 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] XHR responseArrayBuffer attribute

2010-09-27 Thread James Robinson
On Mon, Sep 27, 2010 at 2:40 PM, Anne van Kesteren 
annevankeste...@gmail.com wrote:

 (I'm subscribed to webkit-dev with a different address.)

 On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman micha...@google.com
 wrote:
  Yes, if we go with telling xhr up front for the array buffer case, I
 guess
  an enum would be slightly better.

 I do not think this should be told up front. You already need to keep
 the octet buffer in memory for overrideMimeType to work the way it
 does. We designed responseBlob as an optimization so you would not
 have to deal with the other types. I do not think you can optimize the
 reverse with the design as it stands today.


I see the source of confusion.  I take it that your reading of
http://www.w3.org/TR/XMLHttpRequest2/#the-overridemimetype-method is that if
the mime type is ever overriden and there is a subsequent access of
.responseText, the response body must be re-decoded with the encoding
specified by the new mimetype.

WebKit does not  implement this functionality - the response text decoder is
initialized when the first byte is received from the network based on the
override mime type (if present) and response encoding at that time.  The
decoding behavior from this point on does not change.  WebKit does not save
the raw bytes off the network between receiving chunks of data from the
network, instead it decodes chunks as they arrive and saves them as UTF16
strings.  Frankly, being able to arbitrarily change the encoding at any
point and time and ask for the responseText using a different encoding
sounds dumb - but I'm guessing you will say that is a debate for
public-webapps@

- James


 In any event, any discussion on changes to the specification really
 ought to happen on public-weba...@w3.org.

 Cheers,


 --
 Anne van Kesteren
 http://annevankesteren.nl/
 ___
 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] XHR responseArrayBuffer attribute

2010-09-27 Thread James Robinson
On Mon, Sep 27, 2010 at 6:37 PM, Maciej Stachowiak m...@apple.com wrote:


 On Sep 27, 2010, at 3:19 PM, Michael Nordman wrote:

 Webkit's XHR currently does not keep two copies of the data that I can see.
 I think we should avoid that.


 We could keep the raw data around, which hopefully is directly usable as an
 ArrayBuffer backing store, and only translate it to text format when/if the
 client requests responseText.


It would be unfortunate to have to keep the raw data around after the page
access .responseText, given that the overwhelming majority of pages will
touch .responseText and nothing else.  I found when improving the V8 XHR
implementation that the memory footprint of .responseText being held off of
the XHR object itself was often significant so I would be very reluctant to
grow it by an addition 50-100% (depending on encoding) in the common case.

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