Standardizing rendering pipeline / refresh cycle

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

Standardizing rendering pipeline / refresh cycle

L. David Baron
At today's Houdini task force meeting:
https://wiki.css-houdini.org/planning/paris-2015 some of the blink folks
(mainly Ojan Vafai) presented the outline of a proposal for
standardizing some aspects of the rendering pipeline / refresh cycle:
https://docs.google.com/document/d/1Mw6qNw8UAEfW96CXaXRVYPPZjqQS3YdK7v57wFttAhs/edit
which would probably replace at least parts of this bit of HTML:
https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9

Some of the goals of this would be to improve interop in terms of:

 * which states of a document can be painted (e.g., if there's a
   setInterval that makes the background red and a requestAnimationFrame
   that makes the background green, is it ever possible for the
   background to show as red?  Blink proposes the answer should be no)

 * ordering of various events

 * what the current state is when various events fire (e.g., scroll
   events, animation events)

The goal would be to agree on this stuff and evolve to be interoperable
over a reasonably long time frame.


My initial sense is that it seems reasonable to standardize, and we
should work out the details.


I think one of the harder changes for the concrete pieces that they've
proposed so far is that we'd need to make is not calling into our
painting code from anywhere other than nsRefreshDriver::Tick, i.e.,
eliminating the callers in nsViewManager::UpdateWidgetGeometry and
nsViewManager::WillPaintWindow.  At least, that's based on their initial
reports that a bunch of browsers do sometimes display red in the
scenario above.

The current proposal is to work on this in the Houdini task force, since
the right people seem to be there, even though it isn't quite a perfect
fit for the mission of the task force.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Standardizing rendering pipeline / refresh cycle

Eric Shepherd
L. David Baron wrote:

> At today's Houdini task force meeting:
> https://wiki.css-houdini.org/planning/paris-2015 some of the blink folks
> (mainly Ojan Vafai) presented the outline of a proposal for
> standardizing some aspects of the rendering pipeline / refresh cycle:
> https://docs.google.com/document/d/1Mw6qNw8UAEfW96CXaXRVYPPZjqQS3YdK7v57wFttAhs/edit
> which would probably replace at least parts of this bit of HTML:
> https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9
>
> My initial sense is that it seems reasonable to standardize, and we
> should work out the details.
Certainly from the standpoint of documenting layout for Web developers,
it would be helpful if they knew painting and rendering would work the
same way regardless of which browser the user chose to view the content in.

I've been thinking lately that a lot of things like this, where changes
that might affect compatibility are being considered, might benefit from
being released in tandem with the new add-on SDK.

While at first it might seem unrelated, it really is. We're preparing to
move our add-on community over to building add-ons that are strictly
Web-tech based. This is a lot of change for them to go through, so it
might make sense to carefully consider merging as many potentially
breaking changes together as possible so we don't jerk them around too much.

I don't know how much impact this particular change will have on add-on
developers, but I've seen a few suggested browser-compatibility
proposals that might affect existing code, so I thought I'd bring it up.
Stretching out breaking changes over time just makes the pain last
longer. :)

--

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/eshepherd@...>
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Standardizing rendering pipeline / refresh cycle

Robert O'Callahan-3
I think the impact of this on Web developers and add-on developers should
be very limited.

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Standardizing rendering pipeline / refresh cycle

Robert O'Callahan-3
In reply to this post by L. David Baron
On Sun, Aug 30, 2015 at 1:58 AM, L. David Baron <[hidden email]> wrote:

> My initial sense is that it seems reasonable to standardize, and we
> should work out the details.
>

I agree.

I think one of the harder changes for the concrete pieces that they've
> proposed so far is that we'd need to make is not calling into our
> painting code from anywhere other than nsRefreshDriver::Tick, i.e.,
> eliminating the callers in nsViewManager::UpdateWidgetGeometry and
> nsViewManager::WillPaintWindow.  At least, that's based on their initial
> reports that a bunch of browsers do sometimes display red in the
> scenario above.
>

I think that's fine. OMTC made those a bit bogus anyway.

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Standardizing rendering pipeline / refresh cycle

Eric Shepherd
In reply to this post by Robert O'Callahan-3
Robert O'Callahan wrote:
> I think the impact of this on Web developers and add-on developers
> should be very limited.
That was my expectation but it was worth bringing it up. And doing so
may help trigger that thought in the future when a change is planned
that *will* have an impact. Carry on! :)

--

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/eshepherd@...>
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Standardizing rendering pipeline / refresh cycle

jre33p
In reply to this post by L. David Baron
in my perspective the only problem ac-cured on my Firefox ZTE phone. Was the screen light change. Restored automatically when OFF-ON button clicked. NOTHING ELSE.
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout