Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs=-j1 taking up to 80% of memory
Am 03.01.2012 um 04:20 schrieb Soo-Hyun Choi:
Philippe,
On Mon, Jan 2, 2012 at 19:40, Philippe Normand ph...@igalia.com wrote:
On Mon, 2011-12-26 at 21:45 -0800, sachin nikam wrote:
I synced up the latest webkit code base and am trying to build webkit
gtk on ubuntu 11.10 with 4gb of RAM and 4 CPUs
I tried with --makeargs=-j2 but still got ld process terminated
signal[9] error which indicates that it ran out of memory.
I suspect i will still the get the same error with --makeargs=-j1.
Is there any other flag where we can restrict the memory usage?
Regards
Sachin
Can you try with the GNU Gold linker? We use it on the GTK Debug bot.
I have tried GNU gold linker (Version: 2.20.1-3ubuntu7.1) on Ubuntu
10.04 (32-bit) without success. Could you let us know how you have
been successful to build WebKit Debug on 32-bit machines in more
detail? I have tried building Efl Debug, by the way.
Just a side note: I'm building 32bit release builds on my 32bit MBP from 2006
with a set of specific xcode hack that I'm maintaining locally:
Add all {Editing|Render|DOM}AllInOne.cpp files to build, remove all files from
WebCore target that are referenced in those files.
This allows to use build-webkit, with all default features enabled.
I tried this the last time 2 weeks ago, and it worked fine.
I'm not sure if its worth investigating to maintain two Xcode project files,
just for that. If one really wants it, its possible with this trick.
Cheers,
Niko
___
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
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
[webkit-dev] Seeking Reproductions
We've had several reports of hitting an ASSERT I added back in November (relating to plugin creation): https://bugs.webkit.org/show_bug.cgi?id=50312 Unfortunately, none of them reproduce for me. They're likely all caused by certain flash ads on those pages (which are certainly changed by now). If anyone hits this ASSERT, I would very much appreciate an update on the bug (with url). Thank you. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] chromium-cg-mac results
Hi Elliot, It looks like Chromium Mac has successfully moved to Skia. Should we remove the CG expectations for the Chromium Mac port? Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] chromium-cg-mac results
Hi Adam, On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org wrote: Hi Elliot, It looks like Chromium Mac has successfully moved to Skia. I'd wait with this assessment until a version of Chrome with Skia has shipped to stable. Things are looking really good so that should be smooth sailing, but it's a bit early to say we're successfully moved :-) Nico ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] chromium-cg-mac results
On Tue, Jan 3, 2012 at 3:22 PM, Nico Weber tha...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org wrote: It looks like Chromium Mac has successfully moved to Skia. I'd wait with this assessment until a version of Chrome with Skia has shipped to stable. Things are looking really good so that should be smooth sailing, but it's a bit early to say we're successfully moved :-) Fair enough. However, I believe the Skia transition plan called for removing the chromium-cg-mac expectation much earlier than a Skia build shipping to stable. Originally, we were only supposed to have to maintain both sets of expectations for about a month. The transition has taken longer than expected, but it seems like we have sufficient confidence in Skia now that we can remove the chromium-cg-mac expectations. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs=-j1 taking up to 80% of memory
Niko,
On Tue, Jan 3, 2012 at 17:21, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
Just a side note: I'm building 32bit release builds on my 32bit MBP from 2006
with a set of specific xcode hack that I'm maintaining locally:
Add all {Editing|Render|DOM}AllInOne.cpp files to build, remove all files
from WebCore target that are referenced in those files.
This allows to use build-webkit, with all default features enabled.
WebKit Release build with 32-bit machines are fine without any
modification. People seem to have troubles building Debug option with
those machines. Thanks anyway for your note.
Soo-Hyun
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] chromium-cg-mac results
On Tue, Jan 3, 2012 at 3:28 PM, Adam Barth aba...@webkit.org wrote: On Tue, Jan 3, 2012 at 3:22 PM, Nico Weber tha...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org wrote: It looks like Chromium Mac has successfully moved to Skia. I'd wait with this assessment until a version of Chrome with Skia has shipped to stable. Things are looking really good so that should be smooth sailing, but it's a bit early to say we're successfully moved :-) Fair enough. However, I believe the Skia transition plan called for removing the chromium-cg-mac expectation much earlier than a Skia build shipping to stable. Originally, we were only supposed to have to maintain both sets of expectations for about a month. The transition has taken longer than expected, but it seems like we have sufficient confidence in Skia now that we can remove the chromium-cg-mac expectations. Has the skia transition hit beta yet? It seems like as soon as we get it onto a version that is pointing to a branched version of webkit, we should be completely safe to remove the directories on trunk (frankly, I'd agree with Adam that it's probably safe to remove it now, since we can always add them back in if we have to, but I can compromise as well). -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] chromium-cg-mac results
On Tue, Jan 3, 2012 at 8:33 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:28 PM, Adam Barth aba...@webkit.org wrote: On Tue, Jan 3, 2012 at 3:22 PM, Nico Weber tha...@chromium.org wrote: On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org wrote: It looks like Chromium Mac has successfully moved to Skia. I'd wait with this assessment until a version of Chrome with Skia has shipped to stable. Things are looking really good so that should be smooth sailing, but it's a bit early to say we're successfully moved :-) Fair enough. However, I believe the Skia transition plan called for removing the chromium-cg-mac expectation much earlier than a Skia build shipping to stable. Originally, we were only supposed to have to maintain both sets of expectations for about a month. The transition has taken longer than expected, but it seems like we have sufficient confidence in Skia now that we can remove the chromium-cg-mac expectations. Has the skia transition hit beta yet? It seems like as soon as we get it onto a version that is pointing to a branched version of webkit, we should be completely safe to remove the directories on trunk (frankly, I'd agree with Adam that it's probably safe to remove it now, since we can always add them back in if we have to, but I can compromise as well). Remove it. It is a cost on everyone who enlists in WebKit. Those of us who aren't creating new enlistments are not affected much but that doesn't mean it isn't costly. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
