Re: Intent to explore: A declarative low level graphics API that has a simple mapping to CSS

2018-05-03 Thread Joe Walker 
We’ve evaluated the Metalhead proposal and decided not to proceed with it.

Metalhead proposed a really interesting architecture that could plug into
existing web frameworks to increase frame rates, however by by-passing the
DOM, the proposal had the potential to be misused to remove more of the
semantic nature of the web than we are happy with, so we think that avenues
like DOM ChangeList are more fruitful avenue right now.

I’d like to thank Victor for his work on thinking though these ideas and
the innovative proposal.

Thanks for your interest.

Joe

On Tue, May 1, 2018 at 11:35 AM Victor Porof  wrote:

> Hello again :)
>
> Appreciate the great feedback so far!
>
> So I'd like to clear a few things up. There are many unknowns here which
> need exploring before moving further. Particularly we want to retain as
> much of the semantic model of the web while still allowing native-like
> frame rates.
>
> I'd like to spend some time breaking the document up and listing things we
> can do to preserve as much of the semantic model as we can, so please hold
> off for a bit while I do that.
>
> Thanks everyone!
> Victor
>
>
> On Mon, Apr 30, 2018 at 7:03 PM, Victor Porof  wrote:
>
>> Hey folks,
>>
>> Last quarter I've been drafting a roadmap to explore the advantages of a
>> new web API, fundamentally different from the DOM. It's aiming to expose
>> similar core web features, but with predictible cost and performance, in a
>> declarative immediate-mode manner.
>>
>> This research was driven by a desire to reconcile the growing set of
>> differences between today's development practices and existing browser
>> APIs. At the very least, "the UI is a function of state" is a preferred
>> abstraction trend, different from what browsers directly provide yet
>> incredibly prevalent among modern frameworks, so it's worth discussing the
>> implications.
>>
>> "Project Metalhead" is a proposed vector to address that disconnect. It's
>> an alternative to canvas 2D and WebGL, which:
>> * retains accessibility and internationalisation
>> * efficiently renders a direct mapping of existing CSS primitives
>> * supports form controls with native look and feel
>> * makes it easier for web apps to live inside web workers
>> * is specifically designed to work well with frameworks employing a
>> virtual DOM (e.g. React)
>> * can give Mozilla the driving seat for the next round of web performance
>> wins
>>
>> The proposed core graphics API is just a subset of the bigger
>> architectural solution. Investigation is required in order to understand
>> exactly how accessibility, layout and other existing browser behaviour can
>> be a concrete part of this new API. Prior research has given possible but
>> not definitive answers towards making sure there's no room for unintended
>> loss of user control.
>>
>> Obviously such a vector takes us into currently unknown territory, which
>> I'd like us to explore before moving further. I've written a document
>> describing the roadmap, along with details about a proof of concept
>> technical implementation in more detail:
>> https://docs.google.com/document/d/1YLM1_jlTKYvNa04rEHWw6RBEFQO5aAd8vd-S3yXJjI8
>> There's a lot of info there, so be sure to check out the FAQ, alternatives
>> and implementation. The document is open to everyone at Mozilla, but if you
>> need access to it let me know.
>>
>> Here's a video showcasing the expected performance improvements in
>> action: https://www.youtube.com/watch?v=kDrUfmXLrIU
>>
>> Among other things, the above demo is showing WebRender rendering content
>> running in browsers other than Firefox, powered by a proof of concept of
>> the proposed API. This approach intends to mimic a real world native
>> implementation across various browsers, instead of just a simple polyfill.
>>
>> I'd love getting some opinions and a roadmap review for this. Even though
>> what we have right now is a technically flawed proof of concept
>> implementation and incomplete solution, is it worth pursuing this further?
>>
>> If anyone's interested, I'd also be happy to have a conversation on vidyo
>> about how everything works in more detail.
>>
>> Thanks!
>> Victor
>>
>> *This proposal has been circulating outside of browser-arch last week; in
>> the hopes of getting broader feedback I'm posting it here instead.
>> Apologies if you've seen it already.*
>>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Questions about bindings for L20n

2016-06-14 Thread Joe Walker 
On Tue, Jun 14, 2016 at 7:00 AM Axel Hecht  wrote:

> On 14/06/16 05:06, zbranie...@mozilla.com wrote:
> > On Monday, June 13, 2016 at 9:39:32 AM UTC+1, Gijs Kruitbosch wrote:
> >  > Separately, the documentation put forth so far seems to indicate that
> >> the localization itself is also async, on top of the asyncness of the
> >> mutationobserver approach, and that could potentially result in flashes
> >> of unlocalized content, depending on "how" asynchronous that API really
> >> ends up being. (AFAIK, if the API returned an already-resolved promise,
> >> there might be less chance of that than if it actually went off and did
> >> IO off-main-thread, then came back with some results.)
> >
> > The DOM localization that is used in response to MutationObserver is
> sync.
> >
>
> ... unless strings trigger a load, either if the initial suite of
> localizations isn't loaded yet, or the loaded strings trigger a runtime
> error, which requires more l10n files to be loaded. That's obviously
> cached, so it happens at first occasion.
>

I don't think you can say "It's sync unless  in which case it's
async".
If that's that case then from the API consumers point of view, then (deep
voodoo withstanding) it's async.

Joe.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Moving DevTools to top level /devtools directory

2015-07-22 Thread Joe Walker 
Yes, it's something that we'd like to do, but it's not trivial. Sure
creating a new product is easy, and moving bugs is fairly simple, but
educating people is a thing, and fixing everyone's workflows and scripts is
getting annoying, and it probably all adds up to something hard.
So while I'd like to do it, it's behind other more important things (e.g.
moving to /devtools) right now.

Joe.


On Tue, Jul 21, 2015 at 11:37 PM, Kevin Brosnan kbros...@gmail.com wrote:

 [tangentially related] Are there plans ot move DevTools to a product in
 Bugzilla to match this code layout?

 Kevin

 On Tue, Jul 21, 2015 at 2:54 PM, J. Ryan Stinnett jry...@gmail.com
 wrote:

  The DevTools team is planning to move our code out of
  /browser/devtools and /toolkit/devtools and into a new top level
  /devtools directory.
 
  The main goals of this are to reduce confusion for new DevTools
  contributors and help us better organize our work in the future. It
  will also aid future users of the code in understanding what pieces
  they need to include.
 
  There should be no impact to DevTools features shipped in different
  products: Firefox desktop will continue to be the only product that
  ships the DevTools front end, and all others will ship the DevTools
  server only.
 
  It is my understanding that the DevTools team received approval for a
  new top level directory from Brendan several years ago.
 
  Bug: https://bugzil.la/912121
 
  (Replies to dev-platform.)
 
  - Ryan
  ___
  dev-platform mailing list
  dev-platform@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-platform
 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform