Re: C++ standards proposals of potential interest, and upcoming committee meeting
On Mon, Jun 9, 2014 at 2:38 PM, Jeff Gilbert wrote: > - Original Message - > > From: "Rik Cabanier" > > To: "Benoit Jacob" > > Cc: "Botond Ballo" , "dev-platform" < > dev-platform@lists.mozilla.org>, "Jet Villegas" > > > > Sent: Monday, June 9, 2014 2:08:37 PM > > Subject: Re: C++ standards proposals of potential interest, and upcoming > committee meeting > > > > On Mon, Jun 9, 2014 at 1:50 PM, Benoit Jacob > > wrote: > > > > > 2014-06-09 16:27 GMT-04:00 Jet Villegas : > > > > > > > It seems healthy for the core C++ language to explore new territory > here. > > > > Modern primitives for things like pixels and colors would be a good > > > thing, > > > > I think. Let the compiler vendors compete to boil it down to the > CPU/GPU. > > > > > > > > > In the Web world, we have such an API, Canvas 2D, and the "compiler > > > vendors" are the browser vendors. After years of intense competition > > > between browser vendors, and very high cost to all browser vendors, > nobody > > > has figured yet how to make Canvas2D efficiently utilize GPUs. > > > > > > Chrome, IE and Safari all have GPU accelerated backends with good > success. > > Deferred rendering is working very well. > We also use Skia's GL backend on some platforms, and D2D on windows. > They're strictly slower than reimplementing the app in WebGL. Sure, if you're just animating bitmaps with optional filters/compositing WebGL is faster. Drawing paths and text on the GPU requires complex shaders or tesselation and that require a lot of finessing. > > > There are > > > basically two kinds of Canvas2D applications: those for which GPUs have > > > been useless so far, and those which have benefited much more from > getting > > > ported to WebGL, than they did from accelerated Canvas 2D. > > > > > > That is not true. For instance, do you think mozilla's shumway would be > > better and reliable if it was written in WebGL? > It depends on the primitives shumway receives. If Flash uses a 2d-like API > like skia/cairo/etc., then it is probably not worth the effort to > reimplement the awful-for-GL parts of those APIs. > If there's some performant subset that can be identified, then yes, doing > a WebGL path for that would have a higher performance ceiling. Likely a hybrid approach where vectors are rendered by canvas 2D into a bitmap and those bitmaps are then animated by WebGL. A bitmap would be generated when a movieclip has: - a filter - a blend mode - "cache as bitmap" > > > > There will always be the argument for keeping such things out of > Systems > > > > languages, but that school of thought won't use those features > anyway. I > > > > was taught to not divide by 2 because bit-shifting is how you do fast > > > > graphics in C/C++. I sure hope the compilers have caught up and such > > > > trickery is no longer required--Graphics shouldn't be such a black > art. > > > > > > > > --Jet > > > > > > > ___ > > > 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
Re: Firefox 29 users are having problems shutting down the browser
It's certainly possible, the offending bug landed in Firefox 29 and was fixed in Firefox 30 (bug 1006478) On 09/06/2014 8:28 PM, Kyle Huey wrote: This was bug 1006478, no? - Kyle On Tue, Jun 10, 2014 at 8:20 AM, Vladan Djeric wrote: User Advocacy reports that users of Firefox 29 are seeing Firefox take a long time to shut down and that they are getting the "Firefox is already running" error message (i.e. a locked profile) when they try to relaunch Firefox. Can anyone think of any bugs or patches from that time frame that might be responsible? --- We analyzed some of the Telemetry data to try to identify the source of this regression: 1. The time it takes Firefox to shut down "cleanly" (i.e. successfully) is basically unchanged across versions: http://mzl.la/1hCbMMX 2. The distribution of clean shutdown times in Firefox 27+28+29 has an odd secondary peak at 5-8 seconds: * Firefox 26 has a normal distribution: http://mzl.la/1hCezFO (see the histogram on the bottom of the page) * Firefox 27 has a secondary peak between 5 & 8 seconds: http://mzl.la/1hCeFxb * Firefox 28: http://mzl.la/1hCeHVO * Firefox 29: http://mzl.la/1qkiXcD 3. We have information on the number of startups that failed because of a locked profile via the SIMPLE_MEASURES_FAILEDPROFILELOCKCOUNT Telemetry probe. These failed startups are preceded by an unclean shutdown. There was an an increase in the proportion of "failed startups" from Firefox 28 to Firefox 29 although there was also a major improvement in Firefox 26: * Firefox 24: 2.46M startups were preceded by at least one "locked profile" failed startup out of a total 319.58M normal startups. This is a failure rate of 0.770% * Firefox 25: 3.16M / 406.83M = 0.777% * Firefox 26: 3.33M / 468.88M = 0.710% * Firefox 27: 1.26M / 422.52M = 0.298% * Firefox 28: 1.03M / 341.73M = 0.301% * Firefox 29: 276.08K / 71.56M = 0.385% In other words, the proportion of failed startups increased by a quarter in Firefox 29 vs Firefox 28. 4. We did not find any correlations between users getting the "locked profile" message and any particular extension. There is also no correlation with any Flash plug-in version. 5. We also looked at the stacks of temporary hangs (aka "chrome hangs") occurring around shutdown time and we did not find any smoking guns there. Any ideas? ___ 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
Re: Firefox 29 users are having problems shutting down the browser
This was bug 1006478, no? - Kyle On Tue, Jun 10, 2014 at 8:20 AM, Vladan Djeric wrote: > User Advocacy reports that users of Firefox 29 are seeing Firefox take a > long time to shut down and that they are getting the "Firefox is already > running" error message (i.e. a locked profile) when they try to relaunch > Firefox. > > Can anyone think of any bugs or patches from that time frame that might be > responsible? > > --- > > We analyzed some of the Telemetry data to try to identify the source of this > regression: > > 1. The time it takes Firefox to shut down "cleanly" (i.e. successfully) is > basically unchanged across versions: http://mzl.la/1hCbMMX > > 2. The distribution of clean shutdown times in Firefox 27+28+29 has an odd > secondary peak at 5-8 seconds: > > * Firefox 26 has a normal distribution: http://mzl.la/1hCezFO (see the > histogram on the bottom of the page) > * Firefox 27 has a secondary peak between 5 & 8 seconds: > http://mzl.la/1hCeFxb > * Firefox 28: http://mzl.la/1hCeHVO > * Firefox 29: http://mzl.la/1qkiXcD > > 3. We have information on the number of startups that failed because of a > locked profile via the SIMPLE_MEASURES_FAILEDPROFILELOCKCOUNT Telemetry > probe. These failed startups are preceded by an unclean shutdown. > > There was an an increase in the proportion of "failed startups" from Firefox > 28 to Firefox 29 although there was also a major improvement in Firefox 26: > > * Firefox 24: 2.46M startups were preceded by at least one "locked profile" > failed startup out of a total 319.58M normal startups. This is a failure > rate of 0.770% > * Firefox 25: 3.16M / 406.83M = 0.777% > * Firefox 26: 3.33M / 468.88M = 0.710% > * Firefox 27: 1.26M / 422.52M = 0.298% > * Firefox 28: 1.03M / 341.73M = 0.301% > * Firefox 29: 276.08K / 71.56M = 0.385% > > In other words, the proportion of failed startups increased by a quarter in > Firefox 29 vs Firefox 28. > > 4. We did not find any correlations between users getting the "locked > profile" message and any particular extension. There is also no correlation > with any Flash plug-in version. > > 5. We also looked at the stacks of temporary hangs (aka "chrome hangs") > occurring around shutdown time and we did not find any smoking guns there. > > Any ideas? > ___ > 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
Firefox 29 users are having problems shutting down the browser
User Advocacy reports that users of Firefox 29 are seeing Firefox take a long time to shut down and that they are getting the "Firefox is already running" error message (i.e. a locked profile) when they try to relaunch Firefox. Can anyone think of any bugs or patches from that time frame that might be responsible? --- We analyzed some of the Telemetry data to try to identify the source of this regression: 1. The time it takes Firefox to shut down "cleanly" (i.e. successfully) is basically unchanged across versions: http://mzl.la/1hCbMMX 2. The distribution of clean shutdown times in Firefox 27+28+29 has an odd secondary peak at 5-8 seconds: * Firefox 26 has a normal distribution: http://mzl.la/1hCezFO (see the histogram on the bottom of the page) * Firefox 27 has a secondary peak between 5 & 8 seconds: http://mzl.la/1hCeFxb * Firefox 28: http://mzl.la/1hCeHVO * Firefox 29: http://mzl.la/1qkiXcD 3. We have information on the number of startups that failed because of a locked profile via the SIMPLE_MEASURES_FAILEDPROFILELOCKCOUNT Telemetry probe. These failed startups are preceded by an unclean shutdown. There was an an increase in the proportion of "failed startups" from Firefox 28 to Firefox 29 although there was also a major improvement in Firefox 26: * Firefox 24: 2.46M startups were preceded by at least one "locked profile" failed startup out of a total 319.58M normal startups. This is a failure rate of 0.770% * Firefox 25: 3.16M / 406.83M = 0.777% * Firefox 26: 3.33M / 468.88M = 0.710% * Firefox 27: 1.26M / 422.52M = 0.298% * Firefox 28: 1.03M / 341.73M = 0.301% * Firefox 29: 276.08K / 71.56M = 0.385% In other words, the proportion of failed startups increased by a quarter in Firefox 29 vs Firefox 28. 4. We did not find any correlations between users getting the "locked profile" message and any particular extension. There is also no correlation with any Flash plug-in version. 5. We also looked at the stacks of temporary hangs (aka "chrome hangs") occurring around shutdown time and we did not find any smoking guns there. Any ideas? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Tuesday, 10 June 2014 at 4:00pm PDT
Today's MemShrink meeting will be brought to you by MapMemory() safety for the VirtualAlloc() footgun: https://bugzilla.mozilla.org/show_bug.cgi?id=1005849 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 10 June, 4:00 PM PDT * http://arewemeetingyet.com/Los%20Angeles/2014-06-10/16:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposals of potential interest, and upcoming committee meeting
- Original Message - > From: "Rik Cabanier" > To: "Benoit Jacob" > Cc: "Botond Ballo" , "dev-platform" > , "Jet Villegas" > > Sent: Monday, June 9, 2014 2:08:37 PM > Subject: Re: C++ standards proposals of potential interest, and upcoming > committee meeting > > On Mon, Jun 9, 2014 at 1:50 PM, Benoit Jacob > wrote: > > > 2014-06-09 16:27 GMT-04:00 Jet Villegas : > > > > > It seems healthy for the core C++ language to explore new territory here. > > > Modern primitives for things like pixels and colors would be a good > > thing, > > > I think. Let the compiler vendors compete to boil it down to the CPU/GPU. > > > > > > In the Web world, we have such an API, Canvas 2D, and the "compiler > > vendors" are the browser vendors. After years of intense competition > > between browser vendors, and very high cost to all browser vendors, nobody > > has figured yet how to make Canvas2D efficiently utilize GPUs. > > > Chrome, IE and Safari all have GPU accelerated backends with good success. > Deferred rendering is working very well. We also use Skia's GL backend on some platforms, and D2D on windows. They're strictly slower than reimplementing the app in WebGL. > > > > There are > > basically two kinds of Canvas2D applications: those for which GPUs have > > been useless so far, and those which have benefited much more from getting > > ported to WebGL, than they did from accelerated Canvas 2D. > > > That is not true. For instance, do you think mozilla's shumway would be > better and reliable if it was written in WebGL? It depends on the primitives shumway receives. If Flash uses a 2d-like API like skia/cairo/etc., then it is probably not worth the effort to reimplement the awful-for-GL parts of those APIs. If there's some performant subset that can be identified, then yes, doing a WebGL path for that would have a higher performance ceiling. > > > > > There will always be the argument for keeping such things out of Systems > > > languages, but that school of thought won't use those features anyway. I > > > was taught to not divide by 2 because bit-shifting is how you do fast > > > graphics in C/C++. I sure hope the compilers have caught up and such > > > trickery is no longer required--Graphics shouldn't be such a black art. > > > > > > --Jet > > > > > ___ > > 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
Re: C++ standards proposals of potential interest, and upcoming committee meeting
On Mon, Jun 9, 2014 at 1:50 PM, Benoit Jacob wrote: > 2014-06-09 16:27 GMT-04:00 Jet Villegas : > > > It seems healthy for the core C++ language to explore new territory here. > > Modern primitives for things like pixels and colors would be a good > thing, > > I think. Let the compiler vendors compete to boil it down to the CPU/GPU. > > > In the Web world, we have such an API, Canvas 2D, and the "compiler > vendors" are the browser vendors. After years of intense competition > between browser vendors, and very high cost to all browser vendors, nobody > has figured yet how to make Canvas2D efficiently utilize GPUs. Chrome, IE and Safari all have GPU accelerated backends with good success. Deferred rendering is working very well. > There are > basically two kinds of Canvas2D applications: those for which GPUs have > been useless so far, and those which have benefited much more from getting > ported to WebGL, than they did from accelerated Canvas 2D. That is not true. For instance, do you think mozilla's shumway would be better and reliable if it was written in WebGL? > > There will always be the argument for keeping such things out of Systems > > languages, but that school of thought won't use those features anyway. I > > was taught to not divide by 2 because bit-shifting is how you do fast > > graphics in C/C++. I sure hope the compilers have caught up and such > > trickery is no longer required--Graphics shouldn't be such a black art. > > > > --Jet > > > ___ > 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
Re: C++ standards proposals of potential interest, and upcoming committee meeting
2014-06-09 16:27 GMT-04:00 Jet Villegas : > It seems healthy for the core C++ language to explore new territory here. > Modern primitives for things like pixels and colors would be a good thing, > I think. Let the compiler vendors compete to boil it down to the CPU/GPU. In the Web world, we have such an API, Canvas 2D, and the "compiler vendors" are the browser vendors. After years of intense competition between browser vendors, and very high cost to all browser vendors, nobody has figured yet how to make Canvas2D efficiently utilize GPUs. There are basically two kinds of Canvas2D applications: those for which GPUs have been useless so far, and those which have benefited much more from getting ported to WebGL, than they did from accelerated Canvas 2D. Benoit > There will always be the argument for keeping such things out of Systems > languages, but that school of thought won't use those features anyway. I > was taught to not divide by 2 because bit-shifting is how you do fast > graphics in C/C++. I sure hope the compilers have caught up and such > trickery is no longer required--Graphics shouldn't be such a black art. > > --Jet > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposals of potential interest, and upcoming committee meeting
On Mon, Jun 9, 2014 at 1:28 PM, Benoit Jacob
wrote:
> 2014-06-09 16:12 GMT-04:00 Benoit Jacob :
>
> >
> >
> >
> > 2014-06-09 15:56 GMT-04:00 Botond Ballo :
> >
> > - Original Message -
> >> > From: "Benoit Jacob"
> >> > To: "Botond Ballo"
> >> > Cc: "dev-platform"
> >> > Sent: Monday, June 9, 2014 3:45:20 PM
> >> > Subject: Re: C++ standards proposals of potential interest, and
> >> upcoming committee meeting
> >> >
> >> > 2014-06-09 15:31 GMT-04:00 Botond Ballo :
> >> >
> >> > > Cairo-based 2D drawing API (latest revision):
> >> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf
> >> > >
> >> >
> >> > I would like the C++ committee's attention to be drawn to the dangers,
> >> for
> >> > committee, to try to make decisions outside of its domain of
> expertise.
> >> I
> >> > see more potential for harm than for good in having the C++ committee
> >> join
> >> > the ranks of non graphics specialists thinking they know how to do
> >> > graphics...
> >>
> >> Does this caution apply even if the explicit goal of this API is to
> allow
> >> people learning C++ and/or creating simple graphical applications to be
> >> able to do so with minimal overhead (setting up third-party libraries
> and
> >> such), rather than necessarily provide a tool for
> expert-level/heavy-duty
> >> graphics work?
> >>
> >
> > That would ease my concerns a lot, if that were the case, but skimming
> > through the proposal, it explicitly seems not to be the case.
> >
> > The "Motivation and Scope" section shows that this aims to target drawing
> > GUIs and cover other needs of graphical applications, so it's not just
> > about learning or tiny use cases.
> >
> > Even more worryingly, the proposal talks about GPUs and Direct3D and
> > OpenGL and even Mantle, and that scares me, given what we know about how
> > sad it is to have to take an API like Cairo (or Skia, or Moz2D, or Canvas
> > 2D, it doesn't matter) and try to make it efficiently utilize GPUs. The
> > case of a Cairo-like or Skia-like API could totally be made, but the only
> > mention of GPUs should be to say that they are mostly outside of its
> scope;
> > anything more enthusiastic than that confirms fears that the proposal's
> > authors are not talking out of experience.
> >
>
> It's actually even worse than I realized: the proposal is peppered with
> performance-related comments about GPUs. Just search for "GPU" in it, there
> are 42 matches, most of them scarily talking about GPU performance
> characteristics (a typical one is "GPU resources are expensive to copy").
>
> This proposal should either not care at all about GPU details, which would
> be totally fine for a basic software 2D renderer, which could already cover
> the needs of many applications; or, if it were to seriously care about
> running fast on GPUs, it would not use Cairo as its starting point and it
> would look totally different (it would try to lend itself ot seamlessly
> batching and reordering drawing primitives; typically, a declarative /
> scene-graph API would be a better starting point).
>
This is a terrible proposal. For instance:
class surface {
...
void finish();
void flush();
::std::shared_ptr get_device();
content get_content();
void mark_dirty();
void mark_dirty_rectangle(const rectangle& rect);
void set_device_offset(const point& offset);
void get_device_offset(point& offset);
void write_to_png(const ::std::string& filename);
image_surface map_to_image(const rectangle& extents);
void unmap_image(image_surface& image);
bool has_surface_resource() const;
They simply took the Cairo C library and wrapped it up in classes.
Taking something like the Canvas 2D API and adding support for layers,
filters and proper text support would be a better way to go.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Rendering meeting - next Monday
The Rendering meeting is about all things Gfx, Image, Layout, and Media. It takes place every second Monday, at 2:30pm PDT. The next meeting will take place on Monday, June 16 at 2:30 PM US/Pacific if we have agenda items. Please send me any agenda items you may have. If we have none by the end of the week, we will cancel the meeting. -- - Milan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposals of potential interest, and upcoming committee meeting
2014-06-09 16:12 GMT-04:00 Benoit Jacob : > > > > 2014-06-09 15:56 GMT-04:00 Botond Ballo : > > - Original Message - >> > From: "Benoit Jacob" >> > To: "Botond Ballo" >> > Cc: "dev-platform" >> > Sent: Monday, June 9, 2014 3:45:20 PM >> > Subject: Re: C++ standards proposals of potential interest, and >> upcoming committee meeting >> > >> > 2014-06-09 15:31 GMT-04:00 Botond Ballo : >> > >> > > Cairo-based 2D drawing API (latest revision): >> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf >> > > >> > >> > I would like the C++ committee's attention to be drawn to the dangers, >> for >> > committee, to try to make decisions outside of its domain of expertise. >> I >> > see more potential for harm than for good in having the C++ committee >> join >> > the ranks of non graphics specialists thinking they know how to do >> > graphics... >> >> Does this caution apply even if the explicit goal of this API is to allow >> people learning C++ and/or creating simple graphical applications to be >> able to do so with minimal overhead (setting up third-party libraries and >> such), rather than necessarily provide a tool for expert-level/heavy-duty >> graphics work? >> > > That would ease my concerns a lot, if that were the case, but skimming > through the proposal, it explicitly seems not to be the case. > > The "Motivation and Scope" section shows that this aims to target drawing > GUIs and cover other needs of graphical applications, so it's not just > about learning or tiny use cases. > > Even more worryingly, the proposal talks about GPUs and Direct3D and > OpenGL and even Mantle, and that scares me, given what we know about how > sad it is to have to take an API like Cairo (or Skia, or Moz2D, or Canvas > 2D, it doesn't matter) and try to make it efficiently utilize GPUs. The > case of a Cairo-like or Skia-like API could totally be made, but the only > mention of GPUs should be to say that they are mostly outside of its scope; > anything more enthusiastic than that confirms fears that the proposal's > authors are not talking out of experience. > It's actually even worse than I realized: the proposal is peppered with performance-related comments about GPUs. Just search for "GPU" in it, there are 42 matches, most of them scarily talking about GPU performance characteristics (a typical one is "GPU resources are expensive to copy"). This proposal should either not care at all about GPU details, which would be totally fine for a basic software 2D renderer, which could already cover the needs of many applications; or, if it were to seriously care about running fast on GPUs, it would not use Cairo as its starting point and it would look totally different (it would try to lend itself ot seamlessly batching and reordering drawing primitives; typically, a declarative / scene-graph API would be a better starting point). Benoit > > Benoit > > > > >> >> Cheers, >> Botond >> > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposals of potential interest, and upcoming committee meeting
It seems healthy for the core C++ language to explore new territory here. Modern primitives for things like pixels and colors would be a good thing, I think. Let the compiler vendors compete to boil it down to the CPU/GPU. There will always be the argument for keeping such things out of Systems languages, but that school of thought won't use those features anyway. I was taught to not divide by 2 because bit-shifting is how you do fast graphics in C/C++. I sure hope the compilers have caught up and such trickery is no longer required--Graphics shouldn't be such a black art. --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposals of potential interest, and upcoming committee meeting
2014-06-09 15:56 GMT-04:00 Botond Ballo : > - Original Message - > > From: "Benoit Jacob" > > To: "Botond Ballo" > > Cc: "dev-platform" > > Sent: Monday, June 9, 2014 3:45:20 PM > > Subject: Re: C++ standards proposals of potential interest, and upcoming > committee meeting > > > > 2014-06-09 15:31 GMT-04:00 Botond Ballo : > > > > > Cairo-based 2D drawing API (latest revision): > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf > > > > > > > I would like the C++ committee's attention to be drawn to the dangers, > for > > committee, to try to make decisions outside of its domain of expertise. I > > see more potential for harm than for good in having the C++ committee > join > > the ranks of non graphics specialists thinking they know how to do > > graphics... > > Does this caution apply even if the explicit goal of this API is to allow > people learning C++ and/or creating simple graphical applications to be > able to do so with minimal overhead (setting up third-party libraries and > such), rather than necessarily provide a tool for expert-level/heavy-duty > graphics work? > That would ease my concerns a lot, if that were the case, but skimming through the proposal, it explicitly seems not to be the case. The "Motivation and Scope" section shows that this aims to target drawing GUIs and cover other needs of graphical applications, so it's not just about learning or tiny use cases. Even more worryingly, the proposal talks about GPUs and Direct3D and OpenGL and even Mantle, and that scares me, given what we know about how sad it is to have to take an API like Cairo (or Skia, or Moz2D, or Canvas 2D, it doesn't matter) and try to make it efficiently utilize GPUs. The case of a Cairo-like or Skia-like API could totally be made, but the only mention of GPUs should be to say that they are mostly outside of its scope; anything more enthusiastic than that confirms fears that the proposal's authors are not talking out of experience. Benoit > > Cheers, > Botond > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposals of potential interest, and upcoming committee meeting
- Original Message - > From: "Benoit Jacob" > To: "Botond Ballo" > Cc: "dev-platform" > Sent: Monday, June 9, 2014 3:45:20 PM > Subject: Re: C++ standards proposals of potential interest, and upcoming > committee meeting > > 2014-06-09 15:31 GMT-04:00 Botond Ballo : > > > Cairo-based 2D drawing API (latest revision): > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf > > > > I would like the C++ committee's attention to be drawn to the dangers, for > committee, to try to make decisions outside of its domain of expertise. I > see more potential for harm than for good in having the C++ committee join > the ranks of non graphics specialists thinking they know how to do > graphics... Does this caution apply even if the explicit goal of this API is to allow people learning C++ and/or creating simple graphical applications to be able to do so with minimal overhead (setting up third-party libraries and such), rather than necessarily provide a tool for expert-level/heavy-duty graphics work? Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposals of potential interest, and upcoming committee meeting
2014-06-09 15:31 GMT-04:00 Botond Ballo : > Cairo-based 2D drawing API (latest revision): > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf > I would like the C++ committee's attention to be drawn to the dangers, for committee, to try to make decisions outside of its domain of expertise. I see more potential for harm than for good in having the C++ committee join the ranks of non graphics specialists thinking they know how to do graphics... If that helps, we can give a pile of evidence for how having generalist Web circles trying to standardize graphics APIs has repeatedly given unnecessarily poor APIs... Benoit > > Reflection proposals (these are very early-stage proposals, but they > give an idea of the directions people are exploring): > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3987.pdf > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3996.pdf > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4027.pdf > > > The Committee is meeting next week in Rapperswil, Switzerland. I will be > attending. > > If anyone has any feedback on the above proposals, or any other proposals, > or anything else you'd like me to communicate at the meeting, or anything > I can find out for you at the meeting, please let me know! > > Shortly after the meeting I will blog about what happened there - stay > tuned! > > Cheers, > Botond > ___ > 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
C++ standards proposals of potential interest, and upcoming committee meeting
Hi everyone, Here are some C++ standards proposals from the latest committee mailing that I think might be of interest to the Mozilla community: Portable C++ ABI: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf Modules: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf Cairo-based 2D drawing API (latest revision): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf Reflection proposals (these are very early-stage proposals, but they give an idea of the directions people are exploring): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3987.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3996.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4027.pdf The Committee is meeting next week in Rapperswil, Switzerland. I will be attending. If anyone has any feedback on the above proposals, or any other proposals, or anything else you'd like me to communicate at the meeting, or anything I can find out for you at the meeting, please let me know! Shortly after the meeting I will blog about what happened there - stay tuned! Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: Encrypted Media Extensions
On Sun, Jun 1, 2014 at 2:11 PM, Chris Pearce wrote: > I think we should have the UX discussion ASAP, so that we can get on with > implementing it ASAP. > > I don't know where we'll be having that discussion, I don't know how the UX > people and their process works. For Firefox desktop UX discussions, you should reach out to Chad/Madhava and I. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On Fri, Jun 6, 2014 at 8:35 PM, Boris Zbarsky wrote: > https://tbpl.mozilla.org/?tree=Try&rev=e26ab6d5e1e0 says we have quite a > number of things that are in fact assuming that 5 and "5" should test is(). > I'm not sure how much I like throwing in tons of toString() for that case. Why should you need .toString()? Just change the expected result. Like here, http://dxr.mozilla.org/mozilla-central/source/dom/base/test/test_url_empty_port.html#27 is(url.port, 8080, 'URL.port is 8080'); should just become is(url.port, '8080', 'URL.port is 8080'); This is something I could look at fixing when I next have time, if no one else gets to it first. Should be a lot less work than fixing every misuse of nsresult and nsnull in the tree. :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
