On Tue, Sep 4, 2012 at 10:06 PM, Christophe Dumez
wrote:
> On Sep 5, 2012, at 2:22 AM, Adam Barth wrote:
>> Removing operator+= will likely require changes to a number of
>> port-specific files. I'll do my best to remove these, but I might
>> need some help from maintainers of individual ports.
On Sep 5, 2012, at 2:22 AM, Adam Barth wrote:
> Removing operator+= will likely require changes to a number of
> port-specific files. I'll do my best to remove these, but I might
> need some help from maintainers of individual ports. If you're
> interested in helping out, please let me know.
On Wed, Sep 5, 2012 at 12:10 AM, Joshua Bell wrote:
>
> On Tue, Sep 4, 2012 at 8:32 AM, Alexey Proskuryakov wrote:
>
>>
>> 04.09.2012, в 07:43, Pozdnyakov, Mikhail написал(а):
>>
>> req = new XMLHttpRequest();
>> req.open(“GET”, null);
>> ** **
>> the implementation of XMLHttpRequest
On Tue, Sep 4, 2012 at 11:26 PM, Dan Bernstein wrote:
> On Sep 4, 2012, at 5:50 AM, Glenn Adams wrote:
>
> Alternatively, you can compute the with of each character with script
>> (without adding any new feature to WebKit).
>>
>
> Unfortunately, that won't work since I can't access the width of
On Tue, Sep 4, 2012 at 4:22 PM, Adam Barth wrote:
> Removing operator+= will likely require changes to a number of
> port-specific files. I'll do my best to remove these, but I might
> need some help from maintainers of individual ports. If you're
> interested in helping out, please let me know
>
>
> If operator+= cannot be made sufficiently efficient, we could always leave
> the operator there, but have it ASSERT with a message saying to use
> StringBuilder.
>
>
> Please not this. Failing at compile time is much better than failing at
> runtime in debug builds only.
>
> I was only half s
On Sep 4, 2012, at 5:16 PM, Mike Lawther wrote:
> On 5 September 2012 09:44, Dirk Schulze wrote:
> It is very likely that even future code will land with this operator instead
> of StringBuilder.
>
> Not if Adam removes the operator as he proposed earlier :)
>
> If operator+= cannot be made
On 5 September 2012 09:44, Dirk Schulze wrote:
> It is very likely that even future code will land with this operator
> instead of StringBuilder.
Not if Adam removes the operator as he proposed earlier :)
If operator+= cannot be made sufficiently efficient, we could always leave
the operator
On Sep 4, 2012, at 4:44 PM, Dirk Schulze wrote:
> Yes, looks like the efforts didn't went further. Anyway, is there no
> possibility to improve operator+= further? It is very likely that even future
> code will land with this operator instead of StringBuilder. I think it is
> better to try to
operator+ is now efficient (potentially more so than using a StringBuilder if
you can do it all in one statement). operator+= still sucks, and I don't think
we came up with an obvious way to get good performance with the same syntax.
One possibility: we could add operator+=(String&) to StringBu
Yes, looks like the efforts didn't went further. Anyway, is there no
possibility to improve operator+= further? It is very likely that even future
code will land with this operator instead of StringBuilder. I think it is
better to try to change the operator (if possible) instead of people.
Gree
Ah, you're think of operator+, which is now quite efficient. This
thread is about operator+=, which is sadly slower than molasses.
Adam
On Tue, Sep 4, 2012 at 4:38 PM, Dirk Schulze wrote:
> With a short search in the logs I found optimizations for at least
> operator+, but didn't search furt
With a short search in the logs I found optimizations for at least operator+,
but didn't search further:
http://trac.webkit.org/changeset/86330
https://bugs.webkit.org/show_bug.cgi?id=58420
Greetings,
Dirk
On Sep 4, 2012, at 4:31 PM, Adam Barth wrote:
> Do you have a proposal for how that wo
Do you have a proposal for how that would work and/or a link to the
previous discussion?
Adam
On Tue, Sep 4, 2012 at 4:27 PM, Dirk Schulze wrote:
> I thought we had efforts to make String::operator+= use StringBuilder
> somehow? I can remember that we had a discussion on webkit-dev and definit
I thought we had efforts to make String::operator+= use StringBuilder somehow?
I can remember that we had a discussion on webkit-dev and definitely on
bugzilla about improving String::operator+= instead of replacing it with
StringBuilder.
Greetings,
Dirk
On Sep 4, 2012, at 4:22 PM, Adam Barth
As part of the work to deploy efficient string patterns [1] throughout
WebKit, Benjamin and I noticed a bunch of very inefficient code that
uses operator+= with Strings:
String foo;
for (...)
foo += [...];
return foo;
This pattern is particularly inefficient because += mallocs an
entirely new b
A
On Sep 4, 2012, at 8:34 AM, ext Konstantin Tokarev wrote:
>>
>> To get it compiling, I had to patch ANGLE source code and Simon Hausmann told
>> me he is not comfortable in reviewing these patches. So here I am asking for
>> how to proceed. Should I first try to upstream these patches to ANGLE
Hi Milian,
I would upstream the patches to ANGLE and then update the ANGLE revision in
WebKit. If the changes are small, you could upstream them to ANGLE first and
then land them directly in WebKit's copy of ANGLE. Periodically, we update the
ANGLE revision in WebKit with the latest ANGLE sourc
On Tue, Sep 4, 2012 at 8:32 AM, Alexey Proskuryakov wrote:
>
> 04.09.2012, в 07:43, Pozdnyakov, Mikhail написал(а):
>
> req = new XMLHttpRequest();
> req.open(“GET”, null);
> ** **
> the implementation of XMLHttpRequest will try to open URL:
> “/null“. The similar behaviour is with
04.09.2012, в 07:43, Pozdnyakov, Mikhail написал(а):
> req = new XMLHttpRequest();
> req.open(“GET”, null);
>
> the implementation of XMLHttpRequest will try to open URL:
> “/null“. The similar behaviour is with an undefined object given
> as input url (will try to open “/undefined“).
>
>
On Sep 4, 2012, at 5:50 AM, Glenn Adams wrote:
>>
>> Alternatively, you can compute the with of each character with script
>> (without adding any new feature to WebKit).
>
> Unfortunately, that won't work since I can't access the width of individual
> lines produced by formatting a block.
Hi all,
Currently for the following JS code:
req = new XMLHttpRequest();
req.open("GET", null);
the implementation of XMLHttpRequest will try to open URL:
"/null". The similar behaviour is with an undefined object given
as input url (will try to open "/undefined").
It does not seem to be corre
On Tue, Sep 4, 2012 at 8:30 PM, Ryosuke Niwa wrote:
> Can we use ref tests?
I'll try this first.
>
> Alternatively, you can compute the with of each character with script
> (without adding any new feature to WebKit).
>
Unfortunately, that won't work since I can't access the width of individu
31.08.2012, 17:02, "Milian Wolff" :
> Hey there,
>
> the last days I've spent on trying to get a QtWebKit with OpenGL support, see
> https://bugs.webkit.org/show_bug.cgi?id=95466 for an assortment of patches.
>
> To get it compiling, I had to patch ANGLE source code and Simon Hausmann told
> me h
Can we use ref tests?
Alternatively, you can compute the with of each character with script
(without adding any new feature to WebKit).
If neither is possible, then you should use (1) unless the test tests a
platform specific feature; I.e. the feature isnt available on other
platforms.
(3) seems
What is the recommended approach to test cases when one needs to use a CJK
font that covers the test data? I could use DRT text results as expected
but given lack of common font across platforms, that doesn't seem to be
effective.
>From my somewhat limited (i.e., newbie) exposure to WK, I gather o
26 matches
Mail list logo
