P.S. The 1% figure there was a bit harsh, make it 5%...
2014-02-24 7:49 GMT-05:00 Benoit Jacob :
> From your blog post:
>
>> SG 13′s main intended purpose for such an API is to allow people learning
>> C++ and writing graphical applications to do so easily, without having to
>> rely on third-par
From your blog post:
> SG 13′s main intended purpose for such an API is to allow people learning
> C++ and writing graphical applications to do so easily, without having to
> rely on third-party libraries or learning complex APIs. In the long-term,
> however, they would like the drawing API to be
>> I would like to learn more about the tradeoffs between stateful
>> and stateless drawing APIs. If anyone can point me to a resource
>> about this, I would be grateful.
> http://robert.ocallahan.org/2011/09/graphics-api-design.html
> FWIW I don't think any of this affects Mozilla. We aren't goi
On Tue, Feb 11, 2014 at 8:23 PM, Botond Ballo wrote:
> I think at least one of the goals of the standard drawing API is to
> make C++ easier to learn by allowing people learning the language
> to create simple graphical applications without having to set up
> third-party libraries or learn a comp
> It seems to me that we have arrived at the conclusion that a good drawing API
> should be mostly stateless (like Moz2D), instead of Cairo's stateful API. As
> a result we are currently removing all uses of the Cairo API and we will
> eventually remove Cairo from our codebase altogether (in favor
Robert O'Callahan wrote:
asm.js code must go through Web platform APIs
So the preference would be an API that translates easily to canvas-2D?
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https:
On Mon, Feb 10, 2014 at 12:00 PM, Brian Smith wrote:
> I don't think it is fixed in stone that asm.js code must go through
> Web Platform APIs. I believe the requirement is that it must be
> possible to translate asm.js code into Web Platform APIs in a way
> where the result works reasonably. AFA
On Mon, Feb 10, 2014 at 12:00 PM, Brian Smith wrote:
> On Sun, Feb 9, 2014 at 2:54 PM, Robert O'Callahan
> wrote:
> > On Mon, Feb 10, 2014 at 11:49 AM, Brian Smith
> wrote:
> >> It seems likely that if something like Moz2D became the standard API
> then
> >> we'd be able to optimize it more eas
On Sun, Feb 9, 2014 at 2:54 PM, Robert O'Callahan wrote:
> On Mon, Feb 10, 2014 at 11:49 AM, Brian Smith wrote:
>> It seems likely that if something like Moz2D became the standard API then
>> we'd be able to optimize it more easily than we'd be able to optimize an API
>> that worked much differen
On Mon, Feb 10, 2014 at 11:49 AM, Brian Smith wrote:
> On Sun, Feb 9, 2014 at 2:38 PM, Robert O'Callahan
> wrote:
> > I've already given my feedback on the cairo mailing list. Summary: Moz2D
> is
> > the right thing for us, and probably for other application frameworks,
> but
> > for application
On Sun, Feb 9, 2014 at 2:38 PM, Robert O'Callahan wrote:
> I've already given my feedback on the cairo mailing list. Summary: Moz2D is
> the right thing for us, and probably for other application frameworks, but
> for applications that just want to draw their stuff on the screen or to
> print, cai
I've already given my feedback on the cairo mailing list. Summary: Moz2D is
the right thing for us, and probably for other application frameworks, but
for applications that just want to draw their stuff on the screen or to
print, cairo might be a better fit. Anyway ti doesn't really matter to us
wh
It seems to me that we have arrived at the conclusion that a good drawing API
should be mostly stateless (like Moz2D), instead of Cairo's stateful API. As a
result we are currently removing all uses of the Cairo API and we will
eventually remove Cairo from our codebase altogether (in favor of D
The C++ Standards Committee is aiming to standardize a 2D
drawing API in the post-C++14 timeframe. A study group
(SG 13 - Graphics [1]) has been created to investigate
possible approaches.
SG 13 is considering using Cairo as the basis for a
lightweight C++ drawing API [2] [3]. The idea would b
14 matches
Mail list logo
