(Sorry for flooding the list but I need to repeat my reply to put it in
the right thread.)
Seems like I misunderstood the concept. I assumed that the shared
process model means that there could be multiply UI process instances
that uses the same web process, virtually when the second MiniBrows
Thanks a lot. It solve my problem.
Regards,
Diego
On Tue, Aug 31, 2010 at 6:24 PM, Chris Hatko wrote:
> I presume this is a release build ... I ran into this problem myself.
> You can switch to 64Bit OS or turn off "whole program optimization"
> /GL and corresponding linker flag.
>
> Chris
>
>
Hi,
Continuing color management discussion, it would be great to get
advice for some of the questions I have before starting coding up.
There are already some libraries to parser and convert icc profiles.
One of them is little cms[1] and it's being used by many applications,
specially because i
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
2010/9/1 Alexey Proskuryakov :
>
> 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 ques
On Aug 31, 2010, at 6:59 PM, Kenneth Russell wrote:
> On Tue, Aug 31, 2010 at 6:42 PM, Maciej Stachowiak wrote:
>>
>> On Aug 31, 2010, at 5:29 PM, Chris Marrin wrote:
>>
>>>
>>> On Aug 31, 2010, at 5:25 PM, Kenneth Russell wrote:
>>>
>> ...Yes, I did the Google search and you're right th
On Wed, Sep 1, 2010 at 11:43 AM, Chris Marrin wrote:
>
> On Aug 31, 2010, at 6:59 PM, Kenneth Russell wrote:
>
>> On Tue, Aug 31, 2010 at 6:42 PM, Maciej Stachowiak wrote:
>>>
>>> On Aug 31, 2010, at 5:29 PM, Chris Marrin wrote:
>>>
On Aug 31, 2010, at 5:25 PM, Kenneth Russell wrote:
>>
On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:
>
> But I agree with Maciej that all of the public API is transformation
> oriented. Even things like inverse() and transpose() have application in
> doing transforms. I think it would be a stretch to use this 4x4 matrix for
> general purposes.
On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote:
>
> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:
>
>>
>> But I agree with Maciej that all of the public API is transformation
>> oriented. Even things like inverse() and transpose() have application in
>> doing transforms. I think it
On Sep 1, 2010, at 9:52 AM, Igor Trindade Oliveira wrote:
> 2010/9/1 Alexey Proskuryakov :
>>
>> 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
On Sep 1, 2010, at 1:04 PM, Chris Marrin wrote:
> On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote:
>
>> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:
>>
>>>
>>> But I agree with Maciej that all of the public API is transformation
>>> oriented. Even things like inverse() and transpose()
On Sep 1, 2010, at 1:48 PM, Simon Fraser wrote:
> On Sep 1, 2010, at 1:04 PM, Chris Marrin wrote:
>
>> On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote:
>>
>>> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:
>>>
But I agree with Maciej that all of the public API is transformati
On Sep 1, 2010, at 1:48 PM, Simon Fraser wrote:
> On Sep 1, 2010, at 1:04 PM, Chris Marrin wrote:
>
>> On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote:
>>
>>> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:
>>>
But I agree with Maciej that all of the public API is transformati
In looking at ways to decrease the agony associated with FrameLoader,
I've noticed that there are a whole of 1-line functions on FrameLoader
that just call a similarly named function on FrameLoaderClient without
accessing any member variables other than m_client.
On the one hand, removing these fo
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 th
Originally, I think Maciej and I intended the frame loader client to be private
to frame loader, and all calls were intended to flow through the frame loader.
The same for other clients elsewhere in WebKit. It would be good to be
consistent one way or the other, I guess. Not a very momentous dec
On Wed, 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 cl
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 cl
On Wed, Sep 1, 2010 at 4:36 PM, James Robinson wrote:
> On Wed, 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 ver
Thanks.
So porting PrettyPatch to Python will make good benefit and should have no
drawbacks. I should go ahead.
On Wed, Sep 1, 2010 at 09:21, William Siegrist wrote:
On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote:
> Can we run python scripts on bugs.webkit.org server?
Yes.
-Bill
On Sep 1, 2010, at 4:39 PM, Maciej Stachowiak wrote:
>
> 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
On Wed, Sep 1, 2010 at 5:08 PM, Chris Marrin wrote:
>
> On Sep 1, 2010, at 4:39 PM, Maciej Stachowiak wrote:
>
>>
>> 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
On Sep 1, 2010, at 5:12 PM, Kenneth Russell wrote:
> On Wed, Sep 1, 2010 at 5:08 PM, Chris Marrin wrote:
>>
>> On Sep 1, 2010, at 4:39 PM, Maciej Stachowiak wrote:
>>
>>>
>>> On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:
>>>
Ken's PODRedBlackTree patch has made me go back and ta
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 se
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?
- Maciej
>
> On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:
>
>>
>> Ken's PODRedBlackTree patch has made me go back
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 di
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.
I would be happy to not add another Arena client, but the primary
reason I need an arena is not just for performance but to avoid having
to keep track of all of the objects I need to delete.
Is there any consensus yet on how to proceed with
https://bugs.webkit.org/show_bug.cgi?id=45059 ? I'm conce
Sorry, I seemed to have missed this thread. Please do not rewrite scripts
just to rewrite them in a language you like. WebKit's dependency on Ruby is
here to stay. Just because python is common at Google does not make it
universal.
-Sam
On Wed, Sep 1, 2010 at 4:48 PM, TAMURA, Kent wrote:
> Tha
Here are the list of files in the project which use ruby:
Scripts/check-for-inappropriate-files-in-framework:#!/usr/bin/env ruby
Scripts/check-for-webkit-framework-include-consistency:#!/usr/bin/env ruby
Scripts/clean-header-guards:#!/usr/bin/ruby
Scripts/roll-over-ChangeLogs:#!/usr/bin/env ruby
i
Hi,
On Tue, Aug 31, 2010 at 7:56 AM, TAMURA, Kent wrote:
> Do we have any recommendation of programming language for scripts such as
> WebKitTools/Scripts?
> It seems new scripts are written by Python and Ruby code is very rare.
>
> Is it reasonable to port a Ruby script to Python?
> I tried to
Hi Sam,
Did you see the reply I sent on this thread? There are actually decent
reasons to rewrite the code into Python, to simplify and speed up the
new-run-webkit-tests implementation. Given that, do you still object
to the patch landing (since the work has already been done)?
-- Dirk
On Wed, S
>From reading this thread and the bug, it sounds like there is one key issue
installing something new on build machines.
As discussed before in regards to python, there was a desire not to go above
a certain version so that the tiger build machine could run a script. That
seemed reasonable to me.
On Sep 1, 2010, at 9:28 PM, Dirk Pranke wrote:
> Hi Sam,
>
> Did you see the reply I sent on this thread? There are actually decent
> reasons to rewrite the code into Python, to simplify and speed up the
> new-run-webkit-tests implementation. Given that, do you still object
> to the patch landin
On Sep 1, 2010, at 10:46 PM, David Levin wrote:
> From reading this thread and the bug, it sounds like there is one key issue
> installing something new on build machines.
>
> As discussed before in regards to python, there was a desire not to go above
> a certain version so that the tiger bui
Oh, I didn't see your second post either. Sounds like porting everything
into Python would speed up new-run-webkit-tests? Then I'm all for it. I
think other folks would be equally convinced as well if you could kindly
measure the time difference between Ruby + Python + shell script
implementatio
I suspect that Maciej is right and whatever speedup we would see would
be inconsequential. It's still a slightly cleaner design to not have
to shell out to Ruby from Python, jumping from one scripting language
to another. The deadlocking issue is a serious issue, blocking us from
increasing our usa
37 matches
Mail list logo
