Layout planning worksheet

[Robert O'Callahan]

The layout team got together (virtually) and came up with a set of work
items and priorities.

https://spreadsheets.google.com/ccc?key=pF_tMaWf14QyuXltBtJtYdw&hl=en

Feedback on these items would be extremely valuable. You can send
feedback directly to me or edit the spreadsheet if you're able. What I'm
particularly interested in:
-- Do the relative priorities make sense?
-- Are there any big blind spots that we need to think about? (I'm
particularly concerned about this one)

Rob

[Question]

Hi,
I noticed there is an item "Full screen video". What does "Full" exzctly
mean? 1024*768 or 1920*1200? Wouldn't it be a CPU hogging one if it's trying
to play a H.264 video via gst backend?

Thanks.

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

--
>: ~

[Mike Beltzner]

On 23-Mar-09, at 5:46 PM, Robert O'Callahan wrote:

> -- Do the relative priorities make sense?

The comments I had for jst apply here as well. I have a hard time
evaluating this because I'm not as "in" the terminology and features
as you are. Would it be a lot of trouble to add a couple of columns
that briefly go over the benefits of the features? I actually know
more about these line items than I did with content, but still, a
quick "web feature enablement", or "performance improvement"
explanation of what the items buy us would help.

> -- Are there any big blind spots that we need to think about? (I'm
> particularly concerned about this one)

Two things here I can think of:

- animation for XUL (did that thread ever reach a conclusion about
whether SMIL would work here?) which is something application
developers are dying for in terms of remaining competitive with other
apps (think about all the fun transitions that make the iPhone neat)
- Windows 7 support for things like Aero Peek

cheers,
mike

[Peter Weilbacher]

On 03/23/09 22:46, Robert O'Callahan wrote:
> The layout team got together (virtually) and came up with a set of work
> items and priorities.
>
> https://spreadsheets.google.com/ccc?key=pF_tMaWf14QyuXltBtJtYdw&hl=en

Hmm, is that "hidden" for a reason? I need a Google login for this but
did not need one for the content sheet...
Peter.

[Robert O'Callahan]

On 24/3/09 4:06 PM, Question wrote:
> I noticed there is an item "Full screen video". What does "Full" exzctly
> mean? 1024*768 or 1920*1200? Wouldn't it be a CPU hogging one if it's trying
> to play a H.264 video via gst backend?

Depends on how fast the scale operation is. If the graphics backend is
decent we should be able to get the scaling done by the GPU, then it's
basically free.

Rob

[Robert O'Callahan]

On 24/3/09 5:54 PM, Mike Beltzner wrote:
> On 23-Mar-09, at 5:46 PM, Robert O'Callahan wrote:
>
>> -- Do the relative priorities make sense?
>
> The comments I had for jst apply here as well. I have a hard time
> evaluating this because I'm not as "in" the terminology and features as
> you are. Would it be a lot of trouble to add a couple of columns that
> briefly go over the benefits of the features? I actually know more about
> these line items than I did with content, but still, a quick "web
> feature enablement", or "performance improvement" explanation of what
> the items buy us would help.

OK, I've annnotated the items a bit.

>> -- Are there any big blind spots that we need to think about? (I'm
>> particularly concerned about this one)
>
> Two things here I can think of:
>
> - animation for XUL (did that thread ever reach a conclusion about
> whether SMIL would work here?) which is something application developers
> are dying for in terms of remaining competitive with other apps (think
> about all the fun transitions that make the iPhone neat)

I hope that SMIL and CSS transitions will take care of some use cases.
For the rest, I have in mind a JS API for animation that would let
animation libraries plug in easily. Basically it's two methods on
window: 'startAnimation()' and 'stopAnimation()'; while animation is
running we continuously repaint the window at the user's optimal frame
rate. And also a 'beforepaint' event that fires before we paint; an
animation library would handle that event by updating the state of the
window to match the current time. I don't have an item for that, it
depends on the compositor work.

> - Windows 7 support for things like Aero Peek

I have no idea what the API for that is like, so it's hard to say how we
should expose it. Maybe we would expose an API to designate a special
hidden window to be displayed in the Peek box?

To tell the truth, I was half-expecting people to jump up and down and
yell "performance is the only thing that matters in the market today,
let's cut everything that doesn't help performance". Maybe I should do that.

Rob

[Robert O'Callahan]

No idea, it's all mysterious to me.

Rob

[Mike Beltzner]

On 24-Mar-09, at 7:08 AM, Robert O'Callahan wrote:

>> - animation for XUL (did that thread ever reach a conclusion about
>> whether SMIL would work here?) which is something application
>> developers
>> are dying for in terms of remaining competitive with other apps
>> (think
>> about all the fun transitions that make the iPhone neat)
>
> I hope that SMIL and CSS transitions will take care of some use
> cases. For the rest, I have in mind a JS API for animation that
> would let animation libraries plug in easily. Basically it's two
> methods on window: 'startAnimation()' and 'stopAnimation()'; while
> animation is running we continuously repaint the window at the
> user's optimal frame rate. And also a 'beforepaint' event that fires
> before we paint; an animation library would handle that event by
> updating the state of the window to match the current time. I don't
> have an item for that, it depends on the compositor work.

That sounds reasonable, indeed. Shall I lump it in with the compositor
work when I'm approaching this from a prioritization perspective?

>> - Windows 7 support for things like Aero Peek
>
> I have no idea what the API for that is like, so it's hard to say
> how we should expose it. Maybe we would expose an API to designate a
> special hidden window to be displayed in the Peek box?

Rob Arnold has some idea - apparently it will require some changes at
the widget layer that are non-trivial, but do-able. He said he'd
comment here with some details, but some of these are already being
tracked by bug 474054 and other dependencies of bug 474052.

> To tell the truth, I was half-expecting people to jump up and down
> and yell "performance is the only thing that matters in the market
> today, let's cut everything that doesn't help performance". Maybe I
> should do that.

I may, yet! I think it would be best to shake out the list, first, and
make sure that we're balancing enablement (both required and
opportunistic) against performance in terms of the work that's being
scoped.

cheers,
mike

[Samuel Sidler]

On Mar 23, 2009, at 2:46 PM, Robert O'Callahan wrote:

> Feedback on these items would be extremely valuable. You can send
> feedback directly to me or edit the spreadsheet if you're able.

Hey roc,

After thinking a bit about it, there's a few questions I had that I
added to Johnny's thread and that I'm repeating here:

First, how do we plan to test each of these features? For some or most
of them, it might be pretty obvious, but regardless it'd help if the
spreadsheet listed what test infrastructure is going to be used to
test each feature and if a new bit of test infrastructure will be
needed. In the cases of a new test infrastructure, I definitely want
us to think out what needs to be tested and how we're going to do it.
Writing new code with no tests would suck. ;)

Secondly, and related, what security-related testing will be needed
for each of these features? I'm thinking along the line of new fuzzers
(as someone mentioned for XBL2) and security reviews among other
things. (Can we do security reviews prior to writing code as well as
afterwards?)

Finally, can you estimate how long it will take to complete these
features (including time for bug fixes, regression fixes, etc)? Even
if it's off by a lot I think it'd help in estimating the scope of each
of these features and hopefully ensuring we don't try to do too much
in whatever schedule we make for 1.9.2.

Thanks,

-Sam

[Mike Beltzner]

On 24-Mar-09, at 9:55 AM, Samuel Sidler wrote:

> Finally, can you estimate how long it will take to complete these
> features (including time for bug fixes, regression fixes, etc)? Even
> if it's off by a lot I think it'd help in estimating the scope of
> each of these features and hopefully ensuring we don't try to do too
> much in whatever schedule we make for 1.9.2.

This was along the lines of what I was asking for with a "cost"
estimate. Even if it's something like "no idea, but probably pretty
hard taking most of the time of a full engineer for a few months" it
gives us a much better way of balancing priorities.

cheers,
mike

[Robert O'Callahan]

On 25/3/09 1:44 AM, Mike Beltzner wrote:
> That sounds reasonable, indeed. Shall I lump it in with the compositor
> work when I'm approaching this from a prioritization perspective?

Yes.

Rob

[Robert O'Callahan]

On 25/3/09 2:55 AM, Samuel Sidler wrote:
> First, how do we plan to test each of these features? For some or most
> of them, it might be pretty obvious, but regardless it'd help if the
> spreadsheet listed what test infrastructure is going to be used to test
> each feature and if a new bit of test infrastructure will be needed. In
> the cases of a new test infrastructure, I definitely want us to think
> out what needs to be tested and how we're going to do it. Writing new
> code with no tests would suck. ;)

We're not going to write new code with no tests :-).

I'm reluctant to add test info for every feature, it will bloat the
sheet and I'm not sure the information belongs there. Most of the stuff
there is fairly easy to test with existing infrastructure. CSS
transitions might require some extra infrastructure. For compositor the
first thing I'm doing (right now!) is enhancing our test plugin so the
"hoist plugins to toplevel" item is testable.

> Secondly, and related, what security-related testing will be needed for
> each of these features? I'm thinking along the line of new fuzzers (as
> someone mentioned for XBL2) and security reviews among other things.
> (Can we do security reviews prior to writing code as well as afterwards?)

Hardly any of those items have any particular security impact. SVG
pointer-events has some security impact that we'll have to think
carefully about. The good news is that we're not adding any new formats
here (like we added downloadable fonts or video in the current cycle)
... just regular CSS properties and stuff.

> Finally, can you estimate how long it will take to complete these
> features (including time for bug fixes, regression fixes, etc)? Even if
> it's off by a lot I think it'd help in estimating the scope of each of
> these features and hopefully ensuring we don't try to do too much in
> whatever schedule we make for 1.9.2.

Estimation is hard. Nothing on this list really *blocks* 1.9.2 IMHO
although there are several items that we'd really like to have (the P1s,
notably). I don't think anything here should determine the 1.9.2 schedule.

Rob

[Robert O'Callahan]

OK, I can probably do that.

Rob

[Mike Shaver]

On Tue, Mar 24, 2009 at 9:55 AM, Samuel Sidler <s...@mozilla.com> wrote:
> First, how do we plan to test each of these features?
>

> Secondly, and related, what security-related testing will be needed for each
> of these features?
>

> Finally, can you estimate how long it will take to complete these features
> (including time for bug fixes, regression fixes, etc)?

These are good questions in general, but I don't think that anything
other than the last has much bearing on the prioritization of the
work, or filling gaps in the plan. Let's try and focus this thread on
the layout work items, and not a general referendum on software
development practices. :)

The parenthetical "why" additions to each item helps a lot, thanks to
whoever added them.

Mike

[Samuel Sidler]

On Mar 24, 2009, at 11:23 AM, Mike Shaver wrote:

> On Tue, Mar 24, 2009 at 9:55 AM, Samuel Sidler <s...@mozilla.com> wrote:
>> First, how do we plan to test each of these features?
>>
>> Secondly, and related, what security-related testing will be needed
>> for each
>> of these features?
>>
>> Finally, can you estimate how long it will take to complete these
>> features
>> (including time for bug fixes, regression fixes, etc)?
>
> These are good questions in general, but I don't think that anything
> other than the last has much bearing on the prioritization of the
> work, or filling gaps in the plan. Let's try and focus this thread on
> the layout work items, and not a general referendum on software
> development practices. :)

View it as one item instead of three. ;)

The first two are very much related to the third, in that I want to
make sure those first two are considered when determining the third.
Especially if we have to create new test infrastructure.

-Sam

[Christopher Blizzard]

There are a lot of -parity items in here. Are there keywords and/or
different lists that have the various bits we need to have parity with
Opere, IE + the 15 different WebKits that are out there shipping?

--Chris

[Robert O'Callahan]

On 27/3/09 6:36 AM, Christopher Blizzard wrote:
> There are a lot of -parity items in here. Are there keywords and/or
> different lists that have the various bits we need to have parity with
> Opere, IE + the 15 different WebKits that are out there shipping?

There are bugzilla keywords --- parity:Opera or something like that.

Rob