[webkit-dev] Tiger?
I don't see a Tiger buildbot anymore. Does that mean I'm allowed to break the Tiger build? If so, can we rip out all the Tiger-specific code? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Ordering bugmail in committers.py
Hi. The autocompletion feature on bugs.webkit.org is simply great. But for it to work even better it is needed that all contributors listed in committers.py (reviewers and committers) properly make their bugmail (email subscribed to bugs.webkit.org) to be the first one in the list. As a illustration of the situation here we go two example of failing CC additions via the autocompletion feature due to the wrong ordering: Martin Robinson and Adam Treat (tr...@kde.org is the first email listed but atr...@rim.com, the third listed, is the bugmail). It would be great if each contributor could fix its own ordering, so the autocompletion works nicely for everyone. Thanks, -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Add SelectionChange event for content editable regions
It seems that if our aim is to be compatible with the IE event, we should make our implementation as close to the IE one as possible. I’m not sure that firing the same event, but with a different target, will be good for compatibility. Is there some chance this could lead to a webpage that works in IE but fails in our engine, that would have worked fine if we used a different event name? I think that firing the same select event for editable areas in the document as for input and textarea elements might be a mistake, because the functions for querying and working with the selection are not uniform for those elements. Inside the engine we treat these much the same, but in the DOM API they are quite different. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D
For accelerated 2D rendering we created a class called DrawingBuffer. This encapsulates the accelerated drawing surface (usually in the GPU) and the compositing layer used to display that surface on the page. The drawing surface (which is called a Framebuffer Object or FBO) is allocated by GraphicsContext3D, so DrawingBuffer needs a reference to that. Currently this is a weak reference. DrawingBuffer has a ::create() method and you pass the GraphicsContext3D to that method. If you destroy the GraphicsContext3D, DrawingBuffer has a stale pointer. If you were to try to destroy the DrawingBuffer it would attempt to use that pointer (to destroy its FBO) and crash or worse. Currently we have an implicit policy that you should never destroy a GraphicsContext3D before its DrawingBuffers are all destroyed. That works fine in the current use case, CanvasRenderingContext2D. And we can follow that same policy when in the future when we use DrawingBuffer in WebGLRenderingContext. My concern is that this sort of implicit policy can lead to errors in the future when other potential clients of these classes use them. So I posted https://bugs.webkit.org/show_bug.cgi?id=47501. In that patch I move the creation of DrawingBuffer to the GraphicsContext3D and keep back pointers to all the DrawingBuffers allocated so they can be cleaned up when GraphicsContext3D is destroyed. In talking to James R. he's concerned this adds unnecessary complexity and would rather stick with the implicit policy. So is this something I should be concerned about, or is an implicit policy sufficient in this case? - ~Chris cmar...@apple.com ___ 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
On Mon, Oct 11, 2010 at 3:15 PM, Chris Marrin cmar...@apple.com wrote: For accelerated 2D rendering we created a class called DrawingBuffer. This encapsulates the accelerated drawing surface (usually in the GPU) and the compositing layer used to display that surface on the page. The drawing surface (which is called a Framebuffer Object or FBO) is allocated by GraphicsContext3D, so DrawingBuffer needs a reference to that. Currently this is a weak reference. DrawingBuffer has a ::create() method and you pass the GraphicsContext3D to that method. If you destroy the GraphicsContext3D, DrawingBuffer has a stale pointer. If you were to try to destroy the DrawingBuffer it would attempt to use that pointer (to destroy its FBO) and crash or worse. Currently we have an implicit policy that you should never destroy a GraphicsContext3D before its DrawingBuffers are all destroyed. That works fine in the current use case, CanvasRenderingContext2D. And we can follow that same policy when in the future when we use DrawingBuffer in WebGLRenderingContext. My concern is that this sort of implicit policy can lead to errors in the future when other potential clients of these classes use them. So I posted https://bugs.webkit.org/show_bug.cgi?id=47501. In that patch I move the creation of DrawingBuffer to the GraphicsContext3D and keep back pointers to all the DrawingBuffers allocated so they can be cleaned up when GraphicsContext3D is destroyed. In talking to James R. he's concerned this adds unnecessary complexity and would rather stick with the implicit policy. So is this something I should be concerned about, or is an implicit policy sufficient in this case? Before somebody suggests it, I think Chris and I are in agreement that neither GraphicsContext3D nor DrawingBuffer should be RefCounted. They both have clear single-ownership semantics. - James - ~Chris cmar...@apple.com ___ 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
Re: [webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D
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 DrawingBuffer. This encapsulates the accelerated drawing surface (usually in the GPU) and the compositing layer used to display that surface on the page. The drawing surface (which is called a Framebuffer Object or FBO) is allocated by GraphicsContext3D, so DrawingBuffer needs a reference to that. Currently this is a weak reference. DrawingBuffer has a ::create() method and you pass the GraphicsContext3D to that method. If you destroy the GraphicsContext3D, DrawingBuffer has a stale pointer. If you were to try to destroy the DrawingBuffer it would attempt to use that pointer (to destroy its FBO) and crash or worse. Currently we have an implicit policy that you should never destroy a GraphicsContext3D before its DrawingBuffers are all destroyed. That works fine in the current use case, CanvasRenderingContext2D. And we can follow that same policy when in the future when we use DrawingBuffer in WebGLRenderingContext. My concern is that this sort of implicit policy can lead to errors in the future when other potential clients of these classes use them. So I posted https://bugs.webkit.org/show_bug.cgi?id=47501. In that patch I move the creation of DrawingBuffer to the GraphicsContext3D and keep back pointers to all the DrawingBuffers allocated so they can be cleaned up when GraphicsContext3D is destroyed. In talking to James R. he's concerned this adds unnecessary complexity and would rather stick with the implicit policy. So is this something I should be concerned about, or is an implicit policy sufficient in this case? Before somebody suggests it, I think Chris and I are in agreement that neither GraphicsContext3D nor DrawingBuffer should be RefCounted. They both have clear single-ownership semantics. True, although Simon and I just chatted and he pointed out that Refcounting both classes would solve this problem. The fact that GraphicsContext3D wouldn't need a back pointer to DrawingBuffer means we wouldn't have any circular references. I don't think the overhead of refcounting is an issue here, so maybe that would be a simpler solution? - ~Chris cmar...@apple.com ___ 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
On Mon, Oct 11, 2010 at 4:03 PM, Chris Marrin cmar...@apple.com 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 DrawingBuffer. This encapsulates the accelerated drawing surface (usually in the GPU) and the compositing layer used to display that surface on the page. The drawing surface (which is called a Framebuffer Object or FBO) is allocated by GraphicsContext3D, so DrawingBuffer needs a reference to that. Currently this is a weak reference. DrawingBuffer has a ::create() method and you pass the GraphicsContext3D to that method. If you destroy the GraphicsContext3D, DrawingBuffer has a stale pointer. If you were to try to destroy the DrawingBuffer it would attempt to use that pointer (to destroy its FBO) and crash or worse. Currently we have an implicit policy that you should never destroy a GraphicsContext3D before its DrawingBuffers are all destroyed. That works fine in the current use case, CanvasRenderingContext2D. And we can follow that same policy when in the future when we use DrawingBuffer in WebGLRenderingContext. My concern is that this sort of implicit policy can lead to errors in the future when other potential clients of these classes use them. So I posted https://bugs.webkit.org/show_bug.cgi?id=47501. In that patch I move the creation of DrawingBuffer to the GraphicsContext3D and keep back pointers to all the DrawingBuffers allocated so they can be cleaned up when GraphicsContext3D is destroyed. In talking to James R. he's concerned this adds unnecessary complexity and would rather stick with the implicit policy. So is this something I should be concerned about, or is an implicit policy sufficient in this case? Before somebody suggests it, I think Chris and I are in agreement that neither GraphicsContext3D nor DrawingBuffer should be RefCounted. They both have clear single-ownership semantics. True, although Simon and I just chatted and he pointed out that Refcounting both classes would solve this problem. The fact that GraphicsContext3D wouldn't need a back pointer to DrawingBuffer means we wouldn't have any circular references. I don't think the overhead of refcounting is an issue here, so maybe that would be a simpler solution? I'd really prefer not to make them RefCounted. The problem is that GraphicsContext3D and DrawingBuffer are very heavyweight objects, which means we need to manage their lifetimes tightly and avoid leaving them lying around longer than necessary. The exact resource use of these objects depends on the system but a GraphicsContext3D will typically be backed by an OpenGL context, which implies some set of driver resources, and a DrawingBuffer is normally backed by a few megabytes of VRAM. In the current code, there is always a single object responsible for managing the lifetime of a given GraphicsContext3D or a DrawingBuffer which makes it very easy to ensure that they live for as long as necessary but no longer. With a RefCounted object it can be difficult to ensure that all references to a given object go away when necessary. In this particular case DrawingBuffer exists at a slightly higher abstraction layer than GraphicsContext3D. DrawingBuffer depends on GC3D, but there is no dependency the other way (and IMHO there should not be). This means that the lifetime of a DrawingBuffer depends on the underlying GraphicsContext3D, but not the other way 'round. All callers that use or will want to use a DrawingBuffer already have to be aware of the lifetime of the GraphicsContext3D associated with it since the only way to use a DrawingBuffer is by using the GraphicsContext3D API. For those following along at home, the current user of DrawingBuffer is CanvasRenderingContext2D which has an OwnPtrDrawingBuffer and uses a GraphicsContext3D that is guaranteed to outlive the CanvasRenderingContext2D. The next proposed user of DrawingBuffer is WebGLRenderingContext which manages its own GraphicsContext3D via a member OwnPtr. - James - ~Chris cmar...@apple.com ___ 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
On Oct 11, 2010, at 4:34 PM, James Robinson wrote: On Mon, Oct 11, 2010 at 4:03 PM, Chris Marrin cmar...@apple.com 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: ... So is this something I should be concerned about, or is an implicit policy sufficient in this case? Before somebody suggests it, I think Chris and I are in agreement that neither GraphicsContext3D nor DrawingBuffer should be RefCounted. They both have clear single-ownership semantics. True, although Simon and I just chatted and he pointed out that Refcounting both classes would solve this problem. The fact that GraphicsContext3D wouldn't need a back pointer to DrawingBuffer means we wouldn't have any circular references. I don't think the overhead of refcounting is an issue here, so maybe that would be a simpler solution? I'd really prefer not to make them RefCounted. The problem is that GraphicsContext3D and DrawingBuffer are very heavyweight objects, which means we need to manage their lifetimes tightly and avoid leaving them lying around longer than necessary. The exact resource use of these objects depends on the system but a GraphicsContext3D will typically be backed by an OpenGL context, which implies some set of driver resources, and a DrawingBuffer is normally backed by a few megabytes of VRAM. In the current code, there is always a single object responsible for managing the lifetime of a given GraphicsContext3D or a DrawingBuffer which makes it very easy to ensure that they live for as long as necessary but no longer. With a RefCounted object it can be difficult to ensure that all references to a given object go away when necessary. In this particular case DrawingBuffer exists at a slightly higher abstraction layer than GraphicsContext3D. DrawingBuffer depends on GC3D, but there is no dependency the other way (and IMHO there should not be). This means that the lifetime of a DrawingBuffer depends on the underlying GraphicsContext3D, but not the other way 'round. All callers that use or will want to use a DrawingBuffer already have to be aware of the lifetime of the GraphicsContext3D associated with it since the only way to use a DrawingBuffer is by using the GraphicsContext3D API. For those following along at home, the current user of DrawingBuffer is CanvasRenderingContext2D which has an OwnPtrDrawingBuffer and uses a GraphicsContext3D that is guaranteed to outlive the CanvasRenderingContext2D. The next proposed user of DrawingBuffer is WebGLRenderingContext which manages its own GraphicsContext3D via a member OwnPtr. How can you make that guarantee? The GraphicsContext3D is owned by SharedGraphicsContext3D, which is owned by Page. When Page is destroyed, it will destroy the SharedGraphicsContext3D which will destroy the GraphicsContext3D. The associated DrawingBuffers are owned by CanvasRenderingContext2D which are owned by HTMLCanvasElement. These live in the DOM Tree, which should be destroyed when the Page is destroyed. But Elements are refcounted, so what if there is a JavaScript reference to the HTMLCanvasElement. Or what if it's referenced by some other mechanism which does deferred destruction (like a run loop observer or something). Do we guarantee that all these references will be removed before the Page is destroyed? If this is ever not the case and the DrawingBuffer ever happens to get destroyed after the GraphicsContext3D, you will get a crash. or worse. When I say worse, I'm referring to the fact that some of the uses of these graphics resources rely on the graphics context being previously bound. So it's possible in these cases that the wrong context is bound. It's not inconceivable that an exploit can be found that tries to access a Canvas while destroying a Page. Time it just right and maybe you can get access to some pixels from another window, which is a pretty bad security hole. It just feels safer to me to manage the lifetime of these objects explicitly rather than relying on a complex sequence of events. - ~Chris cmar...@apple.com ___ 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
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 DrawingBuffer. This encapsulates the accelerated drawing surface (usually in the GPU) and the compositing layer used to display that surface on the page. The drawing surface (which is called a Framebuffer Object or FBO) is allocated by GraphicsContext3D, so DrawingBuffer needs a reference to that. Currently this is a weak reference. DrawingBuffer has a ::create() method and you pass the GraphicsContext3D to that method. If you destroy the GraphicsContext3D, DrawingBuffer has a stale pointer. If you were to try to destroy the DrawingBuffer it would attempt to use that pointer (to destroy its FBO) and crash or worse. Currently we have an implicit policy that you should never destroy a GraphicsContext3D before its DrawingBuffers are all destroyed. That works fine in the current use case, CanvasRenderingContext2D. And we can follow that same policy when in the future when we use DrawingBuffer in WebGLRenderingContext. My concern is that this sort of implicit policy can lead to errors in the future when other potential clients of these classes use them. So I posted https://bugs.webkit.org/show_bug.cgi?id=47501. In that patch I move the creation of DrawingBuffer to the GraphicsContext3D and keep back pointers to all the DrawingBuffers allocated so they can be cleaned up when GraphicsContext3D is destroyed. In talking to James R. he's concerned this adds unnecessary complexity and would rather stick with the implicit policy. So is this something I should be concerned about, or is an implicit policy sufficient in this case? Before somebody suggests it, I think Chris and I are in agreement that neither GraphicsContext3D nor DrawingBuffer should be RefCounted. They both have clear single-ownership semantics. True, although Simon and I just chatted and he pointed out that Refcounting both classes would solve this problem. The fact that GraphicsContext3D wouldn't need a back pointer to DrawingBuffer means we wouldn't have any circular references. I don't think the overhead of refcounting is an issue here, so maybe that would be a simpler solution? I think having two independent objects that must be deleted in a specific order, or else you crash, is a hazardous design. APIs (even internal APIs) are better when they do not have a way to be used wrong. So, I think this should be changed one way or the other. I have to say that to my taste, refcounting seems like a cleaner solution than ad-hoc weak pointers. I'm skeptical of the claim that refcounting is not good for a heavyweight object. If there's really a time when special resources (VRAM, etc) need to be freed at a known point in program code, then it may be better to have an explicit close type function instead of counting on the destructor. On the other hand, this might end up being roughly equivalent to the clear backpointers solution, but moves the complexity of being in a possibly-invalid state from DrawingBuffer to GraphicsContext3D. Either way, I am pretty confident that a design where objects must be destroyed in a specific order is not the best choice. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Add SelectionChange event for content editable regions
On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler da...@apple.com wrote: It seems that if our aim is to be compatible with the IE event, we should make our implementation as close to the IE one as possible. I’m not sure that firing the same event, but with a different target, will be good for compatibility. Is there some chance this could lead to a webpage that works in IE but fails in our engine, that would have worked fine if we used a different event name? The goal is to provide developers a way to detect selection change. The idea was that if we had multiple editable regions, developers often want to know which of those editable regions have the selection. Of course, they could walk the DOM upwards from the current selection to find the editable root but I can't think of cases where developers want to receive the document node as the target (maybe useful if we had multiple iframes with design mode on?) because they almost always have the access to the document node. I think that firing the same select event for editable areas in the document as for input and textarea elements might be a mistake, because the functions for querying and working with the selection are not uniform for those elements. Inside the engine we treat these much the same, but in the DOM API they are quite different. Agreed. Alex pointed out that it might be better to have an extra event property (e.g. webkitEditableRoot) that points to the editable root or other element and make target always point to the document node for compatibility. Do you like this design better? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] X-Purpose, again!
On Oct 9, 2010, at 7:11 AM, Gavin Peters (蓋文彼德斯) wrote: On 8 October 2010 12:02, Dan Bernstein m...@apple.com wrote: On Oct 8, 2010, at 6:26 AM, Gavin Peters (蓋文彼德斯) wrote: In particular, Safari sends X-Purpose: preview headers on requests for resources and subresources motivated by the previw feature of Safari. That’s incorrect. The header is only present in the request for the main resource. Thanks for the correction. Can you tell me why that decision was made? This enables cached subresources to be shared between normal loading of pages and loading for preview purposes.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
