For the past few weeks I've been working on bug 753, a refactoring of the image classes related to animated images and frames. It's a huge patch (diffstat: 96 files changed, 2103 insertions(+), 3206 deletions(-)), but it's finally done, and that's why I'm writing this: to find out if we want to land it for 1.9.2.
First, the downsides. This patch removes the interfaces nsIImage and gfxIImageFrame, and changes the imgIContainer interface. This means that both script and binary compatibility will be affected for anyone who uses those interfaces. Also, it's a large patch, and inherently risky.
The upsides are that several people have based somewhat important patches on my work in bug 753, namely Rob Arnold with his Aero peek (Windows 7-only) patch in bug 501490, and Bobby Holley with decode-on- draw in bug 435296.
Aero peek is something that we probably want to have for Windows 7 compatibility, but it might be possible to port the Aero peek patch to the old API (at significant development cost, of course).
Decode-on-draw is a feature that should make pageload faster and memory use less, and it's something that mobile developers have said they'd like to have. It's basically impossible to make this happen without bug 753's changes.
So, what are your thoughts? Should I try landing bug 753 (very soon?) Should we hold off until we reopen trunk for 1.9.3 development?
On 20-Jul-09, at 5:29 PM, Robert O'Callahan wrote:
> On 21/7/09 8:20 AM, Joe Drew wrote: >> So, what are your thoughts? Should I try landing bug 753 (very soon?) >> Should we hold off until we reopen trunk for 1.9.3 development?
> I'm in favour of landing it. Although it's a large patch, it's > mostly restructuring, not making deep changes.
Getting this change in for 1.9.2 will allow us to ship a Firefox 3.6 that coincides with the estimated street date of Windows 7, and this patch is pre-requisite for the Aero Peek work that Rob Arnold is doing. I'm therefore also supportive.
roc: would landing it now jeopardize the stabilization work for the other areas? if not, I suggest we get joe to land it later tonight so we can feel the effects immediately.
> roc: would landing it now jeopardize the stabilization work for the > other areas? if not, I suggest we get joe to land it later tonight so we > can feel the effects immediately.
I don't think it stomps on anyone else. I agree with your suggestion.
On Jul 20, 2009, at 2:39 PM, Robert O'Callahan wrote:
> On 21/7/09 9:38 AM, Mike Beltzner wrote: >> roc: would landing it now jeopardize the stabilization work for the >> other areas? if not, I suggest we get joe to land it later tonight >> so we >> can feel the effects immediately.
> I don't think it stomps on anyone else. I agree with your suggestion.
> For the past few weeks I've been working on bug 753, a refactoring of > the image classes related to animated images and frames. It's a huge > patch (diffstat: 96 files changed, 2103 insertions(+), 3206 > deletions(-)), but it's finally done, and that's why I'm writing this: > to find out if we want to land it for 1.9.2.
> First, the downsides. This patch removes the interfaces nsIImage and > gfxIImageFrame, and changes the imgIContainer interface. This means > that both script and binary compatibility will be affected for anyone > who uses those interfaces. Also, it's a large patch, and inherently > risky.
> The upsides are that several people have based somewhat important > patches on my work in bug 753, namely Rob Arnold with his Aero peek > (Windows 7-only) patch in bug 501490, and Bobby Holley with > decode-on-draw in bug 435296.
> Aero peek is something that we probably want to have for Windows 7 > compatibility, but it might be possible to port the Aero peek patch to > the old API (at significant development cost, of course).
> Decode-on-draw is a feature that should make pageload faster and > memory use less, and it's something that mobile developers have said > they'd like to have. It's basically impossible to make this happen > without bug 753's changes.
> So, what are your thoughts? Should I try landing bug 753 (very soon?) > Should we hold off until we reopen trunk for 1.9.3 development?
> Does anyone know a way to find out who will be bitten by the script > and binary compatibility breakage? I mean apart from landing it and > waiting :)
> cheers, > David > On 7/20/09 4:20 PM, Joe Drew wrote: >> Hi everyone,
>> For the past few weeks I've been working on bug 753, a refactoring >> of the image classes related to animated images and frames. It's a >> huge patch (diffstat: 96 files changed, 2103 insertions(+), 3206 >> deletions(-)), but it's finally done, and that's why I'm writing >> this: to find out if we want to land it for 1.9.2.
>> First, the downsides. This patch removes the interfaces nsIImage >> and gfxIImageFrame, and changes the imgIContainer interface. This >> means that both script and binary compatibility will be affected >> for anyone who uses those interfaces. Also, it's a large patch, and >> inherently risky.
>> The upsides are that several people have based somewhat important >> patches on my work in bug 753, namely Rob Arnold with his Aero peek >> (Windows 7-only) patch in bug 501490, and Bobby Holley with decode- >> on-draw in bug 435296.
>> Aero peek is something that we probably want to have for Windows 7 >> compatibility, but it might be possible to port the Aero peek patch >> to the old API (at significant development cost, of course).
>> Decode-on-draw is a feature that should make pageload faster and >> memory use less, and it's something that mobile developers have >> said they'd like to have. It's basically impossible to make this >> happen without bug 753's changes.
>> So, what are your thoughts? Should I try landing bug 753 (very >> soon?) Should we hold off until we reopen trunk for 1.9.3 >> development?