SVG uplift in to Bon Echo

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

SVG uplift in to Bon Echo

Michael Kaply-2
We've investigated the amount of changes made for SVG on the trunk, and
we do not believe it is feasible to bring that code onto the branch.

In addition to the potential instability that might be caused, as well
as the effort it will be to do the merge, it will require additional
resources on our side to maintain two trees.

Where exactly is the push coming from to get these changes into Firefox 2?

Is there any actual verification from the parties involved that SVG on
the trunk makes whatever problem that is trying to be solved better?

Mike Kaply
IBM
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Mike Shaver
On 5/2/06, Michael Kaply <[hidden email]> wrote:
> We've investigated the amount of changes made for SVG on the trunk, and
> we do not believe it is feasible to bring that code onto the branch.

That's definitely news to me, but it's good to know sooner rather than later.

Are you saying that it's infeasible to bring it all, or to bring any
of it?  Having some more detail about which parts (maybe all!) are
infeasibly hard to bring to 1.8 without effectively re-engineering it
would help here, just to make sure we're (OK, *I'm*) caught up to
date.

> In addition to the potential instability that might be caused, as well
> as the effort it will be to do the merge, it will require additional
> resources on our side to maintain two trees.

In the meeting today I asserted (without contrary comment, though it's
possible that Tim had left the meeting by that point) that where we
could use the same code on trunk and branch we would _improve_
maintenance efficiency.  If that's not the case, perhaps because the
set of patches that will land without major change is null, then
that's good information to have too.

> Where exactly is the push coming from to get these changes into Firefox 2?

As discussed in the status meetings a few times, we're interested in
performance, memory use, and some spec compliance fixes, in service of
increasing trends to see (a subset of) SVG used as part of web
applications and toolkits.  We're also seeing some interesting
examples of SVG used in extensions for visualization and other
interface elements.

http://archive.dojotoolkit.org/nightly/tests/widget/test_Chart.html is
one example I found at random.

I apparently didn't do a good job of getting this conversation to the
right people when I started to investigate and discuss this a few
weeks ago, for which I apologize.  It may well be that we can't get to
a good place on the branch with a newer SVG, which is something that I
can emotionally prepare myself for. :)

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Jeff Schiller
In reply to this post by Michael Kaply-2
It's maybe a catch-22.  Since the update only happened to the trunk,
where a great deal of other things have changed, we have no way of
testing this code isolated.  The changes are inter-mixed with all the
other significant updates going on there.

It would be great to test this in a "private" branch build, but then
you encounter the "effort" costs you mention.  

Jeff

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Robert O'Callahan-3
In reply to this post by Michael Kaply-2
Michael Kaply wrote:
> We've investigated the amount of changes made for SVG on the trunk, and
> we do not believe it is feasible to bring that code onto the branch.

Trying to push the entire set of SVG changes from trunk to branch is
completely mad, IMHO. This code is in flux, it has not been tested, and
more major changes are expected so the moment it lands on branch the two
copies will diverge.

It's unfortunate that this was raised in a bon-echo meeting and has
appeared on dev.planning only tangentially. It could have landed without
most Gecko people even being aware of the possibility.

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Jeff Schiller

Robert O'Callahan wrote:
> Michael Kaply wrote:
> > We've investigated the amount of changes made for SVG on the trunk, and
> > we do not believe it is feasible to bring that code onto the branch.
>
> Trying to push the entire set of SVG changes from trunk to branch is
> completely mad, IMHO. This code is in flux, it has not been tested, and
> more major changes are expected so the moment it lands on branch the two
> copies will diverge.

Robert,

I was under the impression that the changes that were being discussed
for uplifting to the branch were not "the entire set of SVG changes"
but only some of the performance improvements that have recently gone
in (specifically Bug 332162).  This is based on the status meeting
minutes here:
http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-18 where it
says: "SVG performance update code seems to be avaialable; Tor gave me
a summary today. I'd be interested in hearing people's opinions on the
cost vs. value on this one.

It sounded like this change was one of the ones you were suggesting
here:
http://weblogs.mozillazine.org/roc/archives/2006/02/anatomy_of_bloat.html
and the comments in the bug sound like this should really help to
improve the performance.

Sorry, this is hard for me to follow from the "outside".  Anyway, if
the plan was to uplift ALL the SVG changes from trunk to branch, I
agree that's probably a little insane.  If the idea was to merge
changes for a couple significant performance-related bugs, then I was
hoping to see that happen for Fx2.

Regards,
Jeff

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Jeff Schiller
I should also clarify that I have no idea of the scope of these
performance improvements, so even the merge of just the performance
improvements to the branch may be risky, I have no clue (but I'm sure
you, tor and others do).

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Jonathan Watt-3
In reply to this post by Jeff Schiller
schiller wrote:
> I was under the impression that the changes that were being discussed
> for uplifting to the branch were not "the entire set of SVG changes"
> but only some of the performance improvements that have recently gone
> in (specifically Bug 332162).  This is based on the status meeting
> minutes here:
> http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-18 where it
> says: "SVG performance update code seems to be avaialable; Tor gave me
> a summary today. I'd be interested in hearing people's opinions on the
> cost vs. value on this one.

Ah... having the words "SVG" and "uplift" in the same bullet point seems to have
led to some confusion. ;-) I'm all for cherry picking select SVG patches for the
branch. And I'm not against a cairo uplift to the branch (I'm just not qualified
to comment either way on the latter.) What I would be against is trying to sync.
the SVG implementation on the branch with the trunk, but if that was never on
the cards...

Jonathan
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Robert O'Callahan-3
Jonathan Watt wrote:

> schiller wrote:
>> I was under the impression that the changes that were being discussed
>> for uplifting to the branch were not "the entire set of SVG changes"
>> but only some of the performance improvements that have recently gone
>> in (specifically Bug 332162).  This is based on the status meeting
>> minutes here:
>> http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-18 where it
>> says: "SVG performance update code seems to be avaialable; Tor gave me
>> a summary today. I'd be interested in hearing people's opinions on the
>> cost vs. value on this one.
>
> Ah... having the words "SVG" and "uplift" in the same bullet point seems
> to have led to some confusion. ;-) I'm all for cherry picking select SVG
> patches for the branch. And I'm not against a cairo uplift to the branch
> (I'm just not qualified to comment either way on the latter.) What I
> would be against is trying to sync. the SVG implementation on the branch
> with the trunk, but if that was never on the cards...

I'm not sure how you would "cherry pick". Is there a small set of
self-contained patches that produce a major performance win? As far as I
know, none of us know what that set might be.

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Michael Kaply-2
In reply to this post by Michael Kaply-2
This is the reply to my note that shaver sent to planning that didn't
get mirrored to the newsgroup:

On 5/2/06, Michael Kaply <[hidden email]> wrote:
 > We've investigated the amount of changes made for SVG on the trunk, and
 > we do not believe it is feasible to bring that code onto the branch.

That's definitely news to me, but it's good to know sooner rather than
later.

Are you saying that it's infeasible to bring it all, or to bring any
of it?  Having some more detail about which parts (maybe all!) are
infeasibly hard to bring to 1.8 without effectively re-engineering it
would help here, just to make sure we're (OK, *I'm*) caught up to
date.

 > In addition to the potential instability that might be caused, as well
 > as the effort it will be to do the merge, it will require additional
 > resources on our side to maintain two trees.

In the meeting today I asserted (without contrary comment, though it's
possible that Tim had left the meeting by that point) that where we
could use the same code on trunk and branch we would _improve_
maintenance efficiency.  If that's not the case, perhaps because the
set of patches that will land without major change is null, then
that's good information to have too.

 > Where exactly is the push coming from to get these changes into
Firefox 2?

As discussed in the status meetings a few times, we're interested in
performance, memory use, and some spec compliance fixes, in service of
increasing trends to see (a subset of) SVG used as part of web
applications and toolkits.  We're also seeing some interesting
examples of SVG used in extensions for visualization and other
interface elements.

http://archive.dojotoolkit.org/nightly/tests/widget/test_Chart.html is
one example I found at random.

I apparently didn't do a good job of getting this conversation to the
right people when I started to investigate and discuss this a few
weeks ago, for which I apologize.  It may well be that we can't get to
a good place on the branch with a newer SVG, which is something that I
can emotionally prepare myself for. :)

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Robert O'Callahan-3
> Are you saying that it's infeasible to bring it all, or to bring any
> of it?  Having some more detail about which parts (maybe all!) are
> infeasibly hard to bring to 1.8 without effectively re-engineering it
> would help here, just to make sure we're (OK, *I'm*) caught up to
> date.

I think landing it to the branch is probably not that hard. Stabilizing
it on the branch is likely to be a lot of work. The problem is that we
won't know how much work until after it's landed.

>> In addition to the potential instability that might be caused, as well
>> as the effort it will be to do the merge, it will require additional
>> resources on our side to maintain two trees.
>
> In the meeting today I asserted (without contrary comment, though it's
> possible that Tim had left the meeting by that point) that where we
> could use the same code on trunk and branch we would _improve_
> maintenance efficiency.

Only if we lock trunk to the branch from now until FF2 ships. That means
getting SVG developers to stop working on architectural improvements (or
features like SMIL) and doing stabilization only. That's a pretty big
change in plans.

Are there specific opportunities we're missing, or pain points we're
hitting, with the current branch SVG implementation?

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Tim Rowley-2
On 5/9/06 3:33 PM, Robert O'Callahan wrote:
> Are there specific opportunities we're missing, or pain points we're
> hitting, with the current branch SVG implementation?

One area that we hear about occasionally, but haven't worked on yet for
the trunk, is the issue of SVG DOM interfaces whose implementation
requires that the frame has been constructed to work properly (ex:
getBBox).  Developers tend to run into this either in onloads (which we
currently fire during xml parse time) and dynamically constructing elements.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Robert O'Callahan-3
T Rowley wrote:

> On 5/9/06 3:33 PM, Robert O'Callahan wrote:
>> Are there specific opportunities we're missing, or pain points we're
>> hitting, with the current branch SVG implementation?
>
> One area that we hear about occasionally, but haven't worked on yet for
> the trunk, is the issue of SVG DOM interfaces whose implementation
> requires that the frame has been constructed to work properly (ex:
> getBBox).  Developers tend to run into this either in onloads (which we
> currently fire during xml parse time) and dynamically constructing
> elements.

XML parse time? ewww

Is there a bug on this? Some of this can be handled using flush
notifications.

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Boris Zbarsky
Robert O'Callahan wrote:
> XML parse time? ewww
>
> Is there a bug on this? Some of this can be handled using flush
> notifications.

Not until we make our XML parser incremental.  At which point it should Just
Work if the getBBox thing flushes...

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Robert O'Callahan-3
Boris Zbarsky wrote:
> Robert O'Callahan wrote:
>> XML parse time? ewww
>>
>> Is there a bug on this? Some of this can be handled using flush
>> notifications.
>
> Not until we make our XML parser incremental.  At which point it should
> Just Work if the getBBox thing flushes...

It doesn't, that's what I mean :-)

Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: SVG uplift in to Bon Echo

Tim Rowley-2
In reply to this post by Robert O'Callahan-3
On 5/9/06 7:23 PM, Robert O'Callahan wrote:

> T Rowley wrote:
>> One area that we hear about occasionally, but haven't worked on yet for
>> the trunk, is the issue of SVG DOM interfaces whose implementation
>> requires that the frame has been constructed to work properly (ex:
>> getBBox).  Developers tend to run into this either in onloads (which we
>> currently fire during xml parse time) and dynamically constructing
>> elements.
>
> XML parse time? ewww
>
> Is there a bug on this?

Not that I know of.

> Some of this can be handled using flush notifications.

One thought of how to fix it would be to change mozilla's current onload
hooking to allow a list of items instead of just one.

-tor

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning