Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl

2013-10-01 Thread Sergio Villar Senin
On 02/10/13 03:19, Anders Carlsson wrote: > Hello, > > I just wanted to let everyone know that we (Apple) are moving away from > DrawingAreaImpl and always using our tiled drawing area. Longer term we’d > like to remove DrawingAreaImpl completely since it was designed back when we > didn’t run

[webkit-dev] PSA: WebKit2 and DrawingAreaImpl

2013-10-01 Thread Anders Carlsson
Hello, I just wanted to let everyone know that we (Apple) are moving away from DrawingAreaImpl and always using our tiled drawing area. Longer term we’d like to remove DrawingAreaImpl completely since it was designed back when we didn’t run in accelerated compositing mode all the time. It’s my

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

2013-10-01 Thread Ryosuke Niwa
On Tue, Oct 1, 2013 at 4:53 PM, James Craig wrote: > Follow-up question: Since this hasn’t made it into the CSS4 spec yet, > should we temporarily use “-webkit-alt” for the property name? I know there > has been a push to move away from vendor prefixes lately, so if there are > no objections, I

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

2013-10-01 Thread Maciej Stachowiak
Sounds ok to add it prefixed. - Maciej On Oct 1, 2013, at 4:53 PM, James Craig wrote: > Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should > we temporarily use “-webkit-alt” for the property name? I know there has been > a push to move away from vendor prefixes la

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

2013-10-01 Thread James Craig
Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should we temporarily use “-webkit-alt” for the property name? I know there has been a push to move away from vendor prefixes lately, so if there are no objections, I propose we use the unprefixed version. On Sep 30, 2013, a

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Zoltan Horvath
On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen wrote: > > So are you proposing to use the system allocator on Windows? > > I’m proposing a two step process: > > (1) Use the system allocator on Windows (and GTK). > (2) If a port maintainer cares to optimize a given port, without too much > disru

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Maciej Stachowiak
On Oct 1, 2013, at 3:47 PM, Geoffrey Garen wrote: >>> To access thread-specific data using pthreads, you first need to take a >>> lock and call pthread_key_create(). Since the whole point of >>> thread-specific data is to avoid taking a lock, the API is useless. >> >> The normal way to do it

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Geoffrey Garen
> So are you proposing to use the system allocator on Windows? I’m proposing a two step process: (1) Use the system allocator on Windows (and GTK). (2) If a port maintainer cares to optimize a given port, without too much disruption to mainline code, they may do so. FWIW, If I were conducting

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Geoffrey Garen
>> To access thread-specific data using pthreads, you first need to take a lock >> and call pthread_key_create(). Since the whole point of thread-specific data >> is to avoid taking a lock, the API is useless. > > The normal way to do it is to use pthread_once to create the key, which does > no

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Maciej Stachowiak
On Oct 1, 2013, at 3:11 PM, Geoffrey Garen wrote: >>> (4) Find a fast API for aligned virtual memory allocation. >>> (5) Find a fast API for committing / decommitting physical memory without >>> releasing virtual memory pages. >> >> Hrm. Isn't this already available via OSAllocator or are you

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Maciej Stachowiak
On Oct 1, 2013, at 3:05 PM, Geoffrey Garen wrote: >>> (3) Find a fast thread-specific data API on the canonical GTK platform. >> >> Threading for GTK+ on non-Mac/non-Windows platforms is essentially >> pthreads. > > To access thread-specific data using pthreads, you first need to take a lock

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Maciej Stachowiak
On Oct 1, 2013, at 3:35 PM, Brent Fulgham wrote: > So are you proposing to use the system allocator on Windows? Or would we keep > using the existing FastMalloc implementation? > > The current malloc logic has been the source of a number of mysterious > crashes on Windows, so reverting to the

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Brent Fulgham
So are you proposing to use the system allocator on Windows? Or would we keep using the existing FastMalloc implementation? The current malloc logic has been the source of a number of mysterious crashes on Windows, so reverting to the system allocator might be a good thing for stability. I don’

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Geoffrey Garen
> Apple's Windows port uses FastMalloc and the last measurements we took show > it to be a large performance gain over the default Windows malloc > implementation. I believe those measurements were taken 5 Windows versions ago. > While this port is only used by iTunes these days, we still would

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Geoffrey Garen
>> (4) Find a fast API for aligned virtual memory allocation. >> (5) Find a fast API for committing / decommitting physical memory without >> releasing virtual memory pages. > > Hrm. Isn't this already available via OSAllocator or are you referring > to the fact that the Posix implementation has

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Geoffrey Garen
>> (3) Find a fast thread-specific data API on the canonical GTK platform. > > Threading for GTK+ on non-Mac/non-Windows platforms is essentially > pthreads. To access thread-specific data using pthreads, you first need to take a lock and call pthread_key_create(). Since the whole point of threa

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Zoltan Horvath
On Tue, Oct 1, 2013 at 11:56 AM, Martin Robinson wrote: > > > Here’s a rough task list: > > > > (1) Define a canonical GTK platform we’ll use for performance > measurement. > > Perhaps the University of Szeged team has some insight into what > platforms they used for comparing allocator performanc

Re: [webkit-dev] EDITBUGS permission?

2013-10-01 Thread Alexey Proskuryakov
(re-sent from correct address) 01 окт. 2013 г., в 11:10, Brendan Long написал(а): > Is this the right mailing list to ask for EDITBUGS permission? This is not a great place, because it's entirely useless noise for most subscribers of this list. says

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Martin Robinson
On Tue, Oct 1, 2013 at 11:34 AM, Geoffrey Garen wrote: > (4) Find a fast API for aligned virtual memory allocation. > (5) Find a fast API for committing / decommitting physical memory without > releasing virtual memory pages. Hrm. Isn't this already available via OSAllocator or are you referrin

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Maciej Stachowiak
On Sep 30, 2013, at 2:48 PM, Geoffrey Garen wrote: > Hi folks. > > I’m planning to remove our years-out-of-date port of TCMalloc, and replace it > with something that takes maximum advantage of Mac and iOS virtual memory, > threading, and security APIs. > > I've heard that TCMalloc has cause

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Oliver Hunt
On Oct 1, 2013, at 11:56 AM, Martin Robinson wrote: > On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen wrote: >>> A 5% regression in page load performance seems pretty serious. >> >> I’m assuming you’re considering the GTK port here, and not the end-of-life >> Qt port. >> >> Are you up for so

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Martin Robinson
On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen wrote: >> A 5% regression in page load performance seems pretty serious. > > I’m assuming you’re considering the GTK port here, and not the end-of-life Qt > port. > > Are you up for some engineering work to adopt a better malloc for GTK? I apprecia

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Geoffrey Garen
> Here’s a rough task list: > > (1) Define a canonical GTK platform we’ll use for performance measurement. > > (2) Measure FastMalloc on/off on that platform. > > Assuming FastMalloc is a significant improvement: > > (1) Refactor GTK APIs so that API-level objects are not allocated/deleted by

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Geoffrey Garen
> A 5% regression in page load performance seems pretty serious. I’m assuming you’re considering the GTK port here, and not the end-of-life Qt port. Are you up for some engineering work to adopt a better malloc for GTK? Here’s a rough task list: (1) Define a canonical GTK platform we’ll use fo

[webkit-dev] EDITBUGS permission?

2013-10-01 Thread Brendan Long
Is this the right mailing list to ask for EDITBUGS permission? I have 16 accepted patches, and it would be nice if I could assign bugs to myself. http://trac.webkit.org/search?q=Patch+by+Brendan+Long My email on the WebKit bug tracker is: b.l...@cablelabs.com signature.asc Description: OpenPGP

Re: [webkit-dev] Changes in QtWebKit development

2013-10-01 Thread Oliver Hunt
On Oct 1, 2013, at 12:50 AM, Allan Sandfeld Jensen wrote: > On Monday 30 September 2013, Oliver Hunt wrote: >> On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen wrote: >>> Some of this is exactly the reason we want to keep Qt WebKit alive. It >>> may never be possible to fully replace Qt WebKi

Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Martin Robinson
On Mon, Sep 30, 2013 at 7:41 PM, Zoltan Horvath wrote: > Based on a 2.5-year-old measurement > (http://webkit.sed.hu/blog/20100302/war-allocators-qtlaunchers-coast) on the > Qt-port, the page loading on the Methanol test suite was 5% faster (avg) > with TCmalloc than the default system allocator

Re: [webkit-dev] Reference count leak with InBandTextTracks?

2013-10-01 Thread Jer Noble
On Oct 1, 2013, at 2:48 AM, Benjamin Dupont (bedupont) wrote: > Hi all, > > I am currently working on the InbandTextTracks in webkit and I am trying to > understand how the memory is released. > > When we launch the track-in-band.html layout test, two in-band text tracks > have been creat

Re: [webkit-dev] Reference count leak with InBandTextTracks?

2013-10-01 Thread Brendan Long
I've been working on the GStreamer version of in-band text tracks, but I haven't looked at the details of how RefPtr works. My guess is that JavaScript is holding those extra refs, and the "clear memory cache" forces a JS garbage collect. On 10/01/2013 03:48 AM, Benjamin Dupont (bedupont) wrote: >

Re: [webkit-dev] Changes in QtWebKit development

2013-10-01 Thread Filip Pizlo
To me the most invasive Qtism is qmake. When can we get rid of that? -Fil > On Oct 1, 2013, at 12:50 AM, Allan Sandfeld Jensen wrote: > >> On Monday 30 September 2013, Oliver Hunt wrote: >>> On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen >>> wrote: >>> Some of this is exactly the reason

[webkit-dev] Reference count leak with InBandTextTracks?

2013-10-01 Thread Benjamin Dupont (bedupont)
Hi all, I am currently working on the InbandTextTracks in webkit and I am trying to understand how the memory is released. When we launch the track-in-band.html layout test, two in-band text tracks have been created and added, the corresponding RefPtr has a refCount equals to three. 1. Why are

Re: [webkit-dev] Changes in QtWebKit development

2013-10-01 Thread Allan Sandfeld Jensen
On Monday 30 September 2013, Oliver Hunt wrote: > On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen wrote: > > Some of this is exactly the reason we want to keep Qt WebKit alive. It > > may never be possible to fully replace Qt WebKit with anything > > Blink/Chromium based. > > I really don’t un