[webkit-dev] commit queue is stucked

2012-10-15 Thread Osztrogonac Csaba

Hi,

It seems CQ is stucked 2 days ago: 
http://queues.webkit.org/queue-status/commit-queue
Is there anyone here to be able to kick it/them?

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


[webkit-dev] MIPS port status update

2012-10-15 Thread Gergely Kis
Dear WebKit Developers,

A quick status update on the MIPS port progress:
- we have a build-only buildslave running (
http://build.webkit.org/builders/Qt%20Linux%20MIPS32R2%20LE%20Release/)
(it is currently failing, a patch was already submitted to:
https://bugs.webkit.org/show_bug.cgi?id=98856)

- we have DFG and LLINT working for MIPS. We are going to start sending in
the patches today or tomorrow. We plan to submit the work in 3 parts, as 3
separate issues in bugzilla:
- common parts, which are used by both LLINT and DFG
- LLINT MIPS implementation
- DFG MIPS implementation

Should we CC someone directly on these bugs to make the reviews easier?

- Our porting effort uses the following git repository as a staging area:
https://github.com/paul99/webkit
The master branch in this repository is a direct mirror of the main
webkit.org trunk branch.
With the mips-master branch we are tracking the master branch, but also add
a few MIPS specific patches that we are preparing for submitting back to
the main webkit repository. Once we get LLINT and DFG accepted, the
difference between the webkit trunk and our mips-master branch will be
minimal: just the patches that were not yet accepted to webkit trunk. No
forking or added exclusive features are intended here in this
repository. We are committed to submit all MIPS support patches to the
webkit.org main repository.

Best Regards,
Gergely
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] commit queue is stucked

2012-10-15 Thread Adam Barth
Will do once I get a stable Internet connection (probably in an hour and a
half).

Adam
 On Oct 15, 2012 4:10 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:

 Hi,

 It seems CQ is stucked 2 days ago: http://queues.webkit.org/**
 queue-status/commit-queuehttp://queues.webkit.org/queue-status/commit-queue
 Is there anyone here to be able to kick it/them?

 br,
 Ossy
 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://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] Transformations precision: double - float

2012-10-15 Thread Gabor Rapcsanyi

On 10/12/2012 11:23 AM, Tom Hudson wrote:

Do you have particular bottleneck functions that you have reason to
believe would benefit from ARM SIMD optimizations? Under what
workloads, and how much benefit?

We've see a few ridiculously expensive transform functions in WebKit
that my colleagues in Chapel Hill might be able to recall, but usually
it's the rendering engines that are hot, not WebKit itself.

Yes, you're right that the rendering engine is usually the basic bottleneck,
but why shouldn't we optimize WebKit where it is possible.
For example the function what you asking is 
TransformationMatrix::multiply().
I made a test which could be speed up with optimizing this matrix 
multiplication.

I uploaded here: https://bugs.webkit.org/show_bug.cgi?id=98913

We have seen places where double math appears to be absolutely
required for correctness: matrix inversion and path convexity testing;
there are some other areas we're experimenting with that seem to
require it as well. You'd probably need to survey WebKit for stability
(or just hack in doubles and run layout tests) to see how many other
places will break if you throw away the extra precision.

I tried it in the Qt port and there were just a few (47) layout fails with
0.0 and -0.0 problems and one or two pixel differences. But we need more
investigations here.

The rest of Chromium's renderer (Skia) uses float, and we've deployed
SSE/NEON and played with float vs double quite a bit there. The
float-double conversion at the WebKit/Skia boundary doesn't seem to
be too much of a drag, but doing it in any sort of inner loop can
really kill performance.

Meanwhile, there are a lot of places where switching from ARM assembly
to NEON in the renderer hasn't given us as much win as we'd hoped for,
which is why the question how much benefit? seems important to
answer before spending too much time polishing a set of typedefs.

Tom

I can say the same as above. If there is a way to optimize WebKit,
but the benefit is just a half or one percent on an avrage page now
or maybe less, why shouldn't we do that, and of course on a specific
page/case we would benefit more.

-Gabor



On Fri, Oct 12, 2012 at 10:08 AM, Gabor Rapcsanyi
rga...@inf.u-szeged.hu wrote:

Yes I agree that we need to do some measures to see the benefits of floats.
But it's not just about the performance and memory gain of the floats, I
would like to make ARM SIMD optimizations for the transformation functions
to fasten up them, but ARM NEON technology only works with floats that's why
I want to change the doubles.
I would prefer a typedef solution to make this configurable as Ryosuke said,
and then the ports could chose whether they need floats, doubles or long
doubles.

- Gabor


On Oct 10, 2012, at 9:00 AM, Gabor Rapcsanyi rga...@inf.u-szeged.hu
wrote:


That was a long time ago and there were no objections

Unless there's something in the spec requiring double precision it makes
sense to move away from double precision throughout WebKit.

I’m a little concerned about this.

The programming interface to the graphics system on OS X uses doubles, so
it’s likely we’ll be introducing float to double conversions for at least
that platform if we change things inside WebKit that are currently doubles
to float en masse.

Similarly, the native data type for numbers in JavaScript is double. So
any time we are passing a number from JavaScript to WebKit it’s likely that
additional double to float conversions will be required as we change
internals to use doubles instead of floats.

On the other hand, there may also be performance boost or memory gains
from using float instead of double.

If we do make this change, I think we need to do performance testing as we
do so, perhaps on more than one platform, to see if these changes are
leading to benefits or not.

I also think that “we should always use float unless a spec mandates
double” is probably not the right rule of thumb. There are many factors
other than “a spec” at play here.

-- Darin


___
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


[webkit-dev] 8 Bit String Handling in Render Text Code

2012-10-15 Thread Michael Saboff
I recently landed r131311 which adds code to handle 8-bit strings in the render 
text path.  The code also puts HTML text into 8-bit strings.

The reason for this announcement is that the handling of 8-bit text on the 
render path is disabled on non-Mac platforms.  Most platforms have platform 
specific text rendering code and that code needs to be updated to handle 8-bit 
text.  For Mac, the platform specific changes are for the complex text 
rendering path only.  The changes involved converting the 8-bit text to a 
16-bit String, adding the 16-bit string to the ComplexTextController so the 
string won't be freed and using the contained 16-bit text with the rest of the 
complex code unchanged.  See ComplexTextController::collectComplexTextRuns() in 
WebCore/platform/graphics/mac/ComplexTextController.cpp.

The new define WTF_USE_8BIT_TEXTRUN is used to control the creation of 8-bit 
TextRun objects.  When this define is not enabled, TextRun's will only contain 
16-bit text and current code should work correctly.  After platform code is 
added to handle 8-bit text in platform specific code, that platform should 
enable WTF_USE_8BIT_TEXTRUN.  Note that all platforms compile with that define 
enabled, but it is likely they'll crash when running the tests.

- Michael

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


Re: [webkit-dev] Transformations precision: double - float

2012-10-15 Thread Benjamin Poulain
On Mon, Oct 15, 2012 at 9:35 AM, Gabor Rapcsanyi rga...@inf.u-szeged.huwrote:

  On 10/12/2012 11:23 AM, Tom Hudson wrote:

 Do you have particular bottleneck functions that you have reason to
 believe would benefit from ARM SIMD optimizations? Under what
 workloads, and how much benefit?

 We've see a few ridiculously expensive transform functions in WebKit
 that my colleagues in Chapel Hill might be able to recall, but usually
 it's the rendering engines that are hot, not WebKit itself.

  Yes, you're right that the rendering engine is usually the basic
 bottleneck,
 but why shouldn't we optimize WebKit where it is possible.
 For example the function what you asking is
 TransformationMatrix::multiply().
 I made a test which could be speed up with optimizing this matrix
 multiplication.
 I uploaded here: https://bugs.webkit.org/show_bug.cgi?id=98913


You are suggesting a massive change to WebKit based on an hypothetical
universe in which a certain function is important.
The problem is the same claim can be done for about any function of WebKit.
You can handcraft a microbenchmark exercising a slow function and redesign
everything to make that particular function fast. Does this add a lot of
value to the project? No so much.

As much as I am in favor of increasing the use of SIMD, especially on ARM,
I am really not a fan of the idea of switching to float on such weak
premises.

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


Re: [webkit-dev] MIPS port status update

2012-10-15 Thread Gavin Barraclough
On Oct 15, 2012, at 7:13 AM, Gergely Kis wrote:
 Should we CC someone directly on these bugs to make the reviews easier?

Likely reviewers would be me, Oliver, Filip or Geoff, feel free to cc.

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


Re: [webkit-dev] 8 Bit String Handling in Render Text Code

2012-10-15 Thread Maciej Stachowiak

On Oct 15, 2012, at 9:56 AM, Michael Saboff msab...@apple.com wrote:

 I recently landed r131311 which adds code to handle 8-bit strings in the 
 render text path.  The code also puts HTML text into 8-bit strings.
 
 The reason for this announcement is that the handling of 8-bit text on the 
 render path is disabled on non-Mac platforms.  Most platforms have platform 
 specific text rendering code and that code needs to be updated to handle 
 8-bit text.  For Mac, the platform specific changes are for the complex text 
 rendering path only.  The changes involved converting the 8-bit text to a 
 16-bit String, adding the 16-bit string to the ComplexTextController so the 
 string won't be freed and using the contained 16-bit text with the rest of 
 the complex code unchanged.  See 
 ComplexTextController::collectComplexTextRuns() in 
 WebCore/platform/graphics/mac/ComplexTextController.cpp.
 
 The new define WTF_USE_8BIT_TEXTRUN is used to control the creation of 8-bit 
 TextRun objects.  When this define is not enabled, TextRun's will only 
 contain 16-bit text and current code should work correctly.  After platform 
 code is added to handle 8-bit text in platform specific code, that platform 
 should enable WTF_USE_8BIT_TEXTRUN.  Note that all platforms compile with 
 that define enabled, but it is likely they'll crash when running the tests.

Minor technicality, but this should be an ENABLE flag, not USE. ENABLE is for 
optional code in WebKit itself, USE is for optional external dependencies.

Regards,
Maciej

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


[webkit-dev] New CSS3 feature : text-align-last

2012-10-15 Thread DongWoo Im
Dear WebKit,

I would like to let you know that I'm trying to implement a new CSS3 feature 
which name is text-align-last.
The specification link is here : http://www.w3.org/TR/css3-text/#text-align-last

This property describes how the last line of a block or a line right before a 
forced line break is aligned.
This feature is already properly supported on IE and Mozilla, currently.

With this property, we can give a text-align style to the last line, or one 
line content.
Especially, this is valuable when we want to use justify style to the last 
line, or one line content.
When we give text-align:justify, current WebKit gives text-align:start to the 
last line of the content.


The bug related to this implementation is 
https://bugs.webkit.org/show_bug.cgi?id=76173 .



Any comments will be kindly appreciated!


Best regards,
Dongwoo.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev