Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Chris Marrin
On Oct 11, 2010, at 5:15 PM, Maciej Stachowiak wrote: On Oct 11, 2010, at 4:03 PM, Chris Marrin wrote: On Oct 11, 2010, at 3:35 PM, James Robinson wrote: On Mon, Oct 11, 2010 at 3:15 PM, Chris Marrin cmar...@apple.com wrote: For accelerated 2D rendering we created a class called

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Adler
On Oct 12, 2010, at 9:47 AM, Chris Marrin wrote: But refcounting is simpler and my current patch has a clear() method on DrawingBuffer which gets rid of all the resources. I could leave that method and change to a refcounted model, so the author can control when the resources are

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Chris Marrin
On Oct 12, 2010, at 10:44 AM, Darin Adler wrote: On Oct 12, 2010, at 9:47 AM, Chris Marrin wrote: But refcounting is simpler and my current patch has a clear() method on DrawingBuffer which gets rid of all the resources. I could leave that method and change to a refcounted model, so the

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread James Robinson
On Tue, Oct 12, 2010 at 9:47 AM, Chris Marrin cmar...@apple.com wrote: On Oct 11, 2010, at 5:15 PM, Maciej Stachowiak wrote: On Oct 11, 2010, at 4:03 PM, Chris Marrin wrote: On Oct 11, 2010, at 3:35 PM, James Robinson wrote: On Mon, Oct 11, 2010 at 3:15 PM, Chris Marrin

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Maciej Stachowiak
On Oct 12, 2010, at 12:44 PM, James Robinson wrote: On Tue, Oct 12, 2010 at 9:47 AM, Chris Marrin cmar...@apple.com wrote: On Oct 11, 2010, at 5:15 PM, Maciej Stachowiak wrote: On Oct 11, 2010, at 4:03 PM, Chris Marrin wrote: On Oct 11, 2010, at 3:35 PM, James Robinson wrote:

Re: [webkit-dev] Pixel test experiment

2010-10-12 Thread James Robinson
To add a concrete data point, http://trac.webkit.org/changeset/69517 caused a number of SVG tests to fail. It required 14 text rebaselines for Mac and a further two more for Leopard (done by Adam Barth). In order to pass the pixel tests in Chromium, it required 1506 new pixel baselines (checked

Re: [webkit-dev] Pixel test experiment

2010-10-12 Thread Adam Barth
On Tue, Oct 12, 2010 at 1:43 PM, James Robinson jam...@google.com wrote: - Do we have the tools and infrastructure needed to do mass rebaselines in WebKit currently?  We've built a number of tools to deal with the Chromium expectations, but since this has been a need unique to Chromium so far

Re: [webkit-dev] ArrayBuffer supprot

2010-10-12 Thread Kenneth Russell
On Fri, Oct 8, 2010 at 2:46 PM, Jian Li jia...@chromium.org wrote: Hi, I am looking into hooking up ArrayBuffer support in FileReader and BlobBuilder. It seems that most of the typed array types (ArrayBuffer, ArrayBufferView, Uint8Array, and etc) have already been implemented in WebKit,

Re: [webkit-dev] ArrayBuffer supprot

2010-10-12 Thread Jian Li
On Tue, Oct 12, 2010 at 2:17 PM, Kenneth Russell k...@google.com wrote: On Fri, Oct 8, 2010 at 2:46 PM, Jian Li jia...@chromium.org wrote: Hi, I am looking into hooking up ArrayBuffer support in FileReader and BlobBuilder. It seems that most of the typed array types (ArrayBuffer,

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Fisher
On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 12, 2010, at 12:44 PM, James Robinson wrote: On Tue, Oct 12, 2010 at 9:47 AM, Chris Marrin cmar...@apple.com wrote: On Oct 11, 2010, at 5:15 PM, Maciej Stachowiak wrote: On Oct 11, 2010, at 4:03 PM, Chris

Re: [webkit-dev] Pixel test experiment

2010-10-12 Thread Jeremy Orlow
On Tue, Oct 12, 2010 at 1:43 PM, James Robinson jam...@google.com wrote: To add a concrete data point, http://trac.webkit.org/changeset/69517 caused a number of SVG tests to fail. It required 14 text rebaselines for Mac and a further two more for Leopard (done by Adam Barth). In order to

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Chris Marrin
On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote: ...So it seems like we have two choices: 1) my current patch, which uses backpointers to manage the lifetime of the weak pointers, or 2) refcounting. My current approach has the advantage that the resources are cleared as soon as the

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Maciej Stachowiak
On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote: On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote: Hmm, I've found weak pointer abstractions to be very useful. The issue with reference counting is that it is easy to introduce memory leaks, and has been mentioned,

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread James Robinson
On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote: On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote: Hmm, I've found weak pointer abstractions to be very useful. The issue with reference counting

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Fisher
On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote: On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote: Hmm, I've found weak pointer abstractions to be very useful. The issue with reference counting

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Fisher
On Tue, Oct 12, 2010 at 6:37 PM, James Robinson jam...@google.com wrote: On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote: On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote: Hmm, I've found weak

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Adler
Not sure it is relevant to this discussion, but WebKit had a weak pointer class back in 2002 and I removed it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Darin Fisher
Caused more harm than good? -Darin On Tue, Oct 12, 2010 at 10:06 PM, Darin Adler da...@apple.com wrote: Not sure it is relevant to this discussion, but WebKit had a weak pointer class back in 2002 and I removed it. -- Darin ___ webkit-dev

Re: [webkit-dev] Pixel test experiment

2010-10-12 Thread Dirk Schulze
Does it support pixel test updates? Is it possible to extend this tool if not? This would limit the maintenance cost and every commiter should rebaseline mac if the change is a progression, or the difference is machine dependent (but not OS dependent). Dirk Am 12.10.2010 um 22:49 schrieb Adam

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Maciej Stachowiak
On Oct 12, 2010, at 10:03 PM, Darin Fisher wrote: On Tue, Oct 12, 2010 at 3:46 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 12, 2010, at 2:37 PM, Darin Fisher wrote: On Tue, Oct 12, 2010 at 1:20 PM, Maciej Stachowiak m...@apple.com wrote: Hmm, I've found weak pointer abstractions

Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

2010-10-12 Thread Maciej Stachowiak
I don't know if this is what Darin (Adler) is referring to, but at one point I think there was a special weak pointer for Nodes to point back to their Document. This turned out to be the wrong design since for Web-compatible behavior you really want the document to stay alive while the node is