220 8882 <77d9e527-b39c-46b1-af0b-62c6b9537bda@isocpp.org> article Path: news.gmane.org!not-for-mail From: malteskarupke@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Comments on 2d api for c++ N3888.pdf Date: Mon, 27 Jan 2014 19:50:06 -0800 (PST) Lines: 276 Approved: news@gmane.org Message-ID: <77d9e527-b39c-46b1-af0b-62c6b9537bda@isocpp.org> References: <9105f9b2-e15d-4bf8-a4a1-65ebc3657eb0@isocpp.org> <16575659.VFgV8LhWkF@tjmaciei-mobl2> <2404400.rGitdhCsJ7@tjmaciei-mobl2> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4170_19733406.1390881006608" X-Trace: ger.gmane.org 1390881000 30996 80.91.229.3 (28 Jan 2014 03:50:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jan 2014 03:50:00 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCTZV5F2UUCRB36RTSLQKGQEJNUYA6A@isocpp.org Tue Jan 28 04:50:09 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f200.google.com ([209.85.128.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W7zgf-0000ET-0w for gclcip-std-proposals@m.gmane.org; Tue, 28 Jan 2014 04:50:09 +0100 Original-Received: by mail-ve0-f200.google.com with SMTP id c14sf14323977vea.7 for ; Mon, 27 Jan 2014 19:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=BCpv64GDuNuxl3C2lfWqIygY19OtQR9Mcc/rKIg0HJ4=; b=r2r5oA62nDXTdnIxUa85Ap/EHPbIK4I3Ikzb8otUNEmFyrzExlPS81cxY+P2seM9L+ k5VoJjj+WyMCnGGhtJtpiJTYbJPtFR6Nb8tuLmKnm56ek5iYvF3zjb/bMOfsptKmvMGt M3J33MJYRLvNg+ZTY1ggOuL3qBcSOWKayghydzwJrRdeBTUw/oYX1ULQ22hH+KB1DTav a6AUaq50sc3deYMr8b/RM76ZuAQKYcubxLir8fi5EBomIzok9VhG0Ehyv5+15QBmkw6A z0cWEhbn2qgRbVynfRdxE2HfLe3sNzVhCnapBX7WNdYM172I/ZXj8+pe3qKF0+u90YUy FnPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=BCpv64GDuNuxl3C2lfWqIygY19OtQR9Mcc/rKIg0HJ4=; b=M62jPvk4Nd96LmBd/aBj9qtcDDaWSiqUySWH6XRNxZ5y2ixApPUoX0No6LxE5tM8W3 Ct2SuDkzGer6GVXo8bfSSEXvKvFOGapwBAjq10E+FyX0rpkoKA0J16ZN+5d3ZI0pyrUg qp3ZfUuM3EM9A8RqgAg26aylP53ROAbOtiHhyYCY+8rCA/eusoUvKYGEZ3jUPKuLtnK3 SL8+66K/WnFoHT4LgSV8SZso4eCpln/dKBv49TBZpNlaKQEca7HUzYQ4rDOu+m6I2hMM QYom+dSF74NJdRCrTsyb66zSBtvA3GV9rOhw3NSn2UBDaBHOXqtTDAqm3xUMvufq1vja MSRQ== X-Gm-Message-State: ALoCoQmEyf8tWEWawFOEB18Lq60lFEEZwNIHbMEvjxaNztVggu2QQ5AlE4nu+bY70cFt8Tbw6oXd X-Received: by 10.58.238.199 with SMTP id vm7mr11698770vec.17.1390881008184; Mon, 27 Jan 2014 19:50:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.96.52 with SMTP id j49ls1897123qge.7.gmail; Mon, 27 Jan 2014 19:50:07 -0800 (PST) X-Received: by 10.140.37.18 with SMTP id q18mr6qgq.20.1390881007226; Mon, 27 Jan 2014 19:50:07 -0800 (PST) In-Reply-To: X-Original-Sender: malteskarupke@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8882 Archived-At: ------=_Part_4170_19733406.1390881006608 Content-Type: text/plain; charset=UTF-8 I think this is a great thing and thank you for doing this. Having a standard 2D graphics library would be great. That being said I disagree with some of the comments so far about what the purpose of this library should be. In my opinion the main point of this library should be to provide simple building blocks and to make it easy to extend the library. Just like you can add any type to a std::unordered_map by implementing std::hash, and like you can print any type with an iostream by overloading operator<<, you should be able to add any type to the 2D graphics library. If I make a "piechart" class that can draw a std::map, it should be easy for you to add that class to your application. One way to do that would be to have a common base type like Qt's QWidget. No matter what your code looks like, if you give me a QWdiget I can add it to my layout. (but ideally I would like a solution that does not rely on inheritance, just like std::hash does not rely on inheritance) I don't think that a standard 2D graphics library has to be the most efficient graphics library around. I believe that attempting that is doomed to fail. Even if it turns out to be very fast now, the standards committee will be playing catch-up with other libraries forever. (and even if it is the fastest, the people who care about speed (game developers) are going to implement their own library anyway) Instead it should be recognized that if you write a library for the standard, you have got a whole different set of opportunities. The main one being that you could define the interface that most 2D drawing will follow in C++. My ideal standard 2D library would be one about which I could say "if you implement your drawing in this, it won't be the fastest, but it will be fast enough in almost all cases, and Qt has a compatibility layer that will make your code work in all Qt applications. And so does GTK+. And so does SDL. So unless performance is super important to you, just use this." (that being said performance should not be ignored and I would much prefer abstractions which are almost free like those used in as opposed to those used in iostreams) Cheers, Malte On Monday, January 27, 2014 7:16:14 PM UTC-5, Michael McLaughlin wrote: > > I'm in the process of providing more detailed answers because the I > appreciate the earlier feedback and feel that it is helpful. As such I > think each post deserve a detailed response. > > But I just wanted to pause to say that I think that Thiago's post is > a excellent summary of things as they stand going in to Issaquah. > > Elsewhere, in a humorous context, I summarized it as follows: If N3888 > were incorporated into the Standard as-is, I would feel compelled to > request that the Issaquah Police Department investigate the possibility > that we had all been unknowingly exposed to some substance with > psychotropic properties. :) > > -Mike > > > On Mon, Jan 27, 2014 at 7:01 PM, Thiago Macieira > > wrote: > >> On segunda-feira, 27 de janeiro de 2014 18:06:49, Felipe Magno de Almeida >> wrote: >> > > I'm arguing that we need an efficient C++ library more than we need a >> > > generic one. So I'm arguing to *first* get what matters, and then >> > > generalise. >> > If what you mean by first is that it is included to the C++ standard >> > library, then >> > I would be against. Not that I can vote :). If you meant someone >> writing a >> > new C++ library, then I'm always for it. The more the merrier, of >> course. >> >> That's partially what I meant. In my opinion, having a library that cannot >> possibly do ARGB32 efficiently is a disservice to C++ developers, even if >> it can >> also do ARGB48, ARGB64, RGB565, YUV420, HSV, and other crazy pixel >> formats. >> >> I meant that we first need to figure out the API, we need to get started >> somewhere. Let's figure out what we need, how it would work, and how it >> can be >> implemented efficiently. Without a reference implementation that passes >> basic >> quality check, we'll get nowhere. This is why the current proposal is >> based on >> Cairo: it implements today's technology efficiently, even if the API is >> not very >> C++-like yet. >> >> After we get that, we can study generalisations without compromising the >> quality. Once that is done, it can be proposed to the standard. >> >> We're still trying to get step 1 done. >> -- >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >> Software Architect - Intel Open Source Technology Center >> PGP/GPG: 0x6EF45358; fingerprint: >> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to std-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> Visit this group at >> http://groups.google.com/a/isocpp.org/group/std-proposals/. >> > > -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_4170_19733406.1390881006608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is a great thing and thank you for doing this= .. Having a standard 2D graphics library would be great.

That being s= aid I disagree with some of the comments so far about what the purpose of t= his library should be. In my opinion the main point of this library should = be to provide simple building blocks and to make it easy to extend the libr= ary. Just like you can add any type to a std::unordered_map by implementing= std::hash, and like you can print any type with an iostream by overloading= operator<<, you should be able to add any type to the 2D graphics li= brary. If I make a "piechart" class that can draw a std::map<std::string= , float>, it should be easy for you to add that class to your applicatio= n. One way to do that would be to have a common base type like Qt's QWidget= .. No matter what your code looks like, if you give me a QWdiget I can add i= t to my layout. (but ideally I would like a solution that does not rely on = inheritance, just like std::hash does not rely on inheritance)

I don= 't think that a standard 2D graphics library has to be the most efficient g= raphics library around. I believe that attempting that is doomed to fail. E= ven if it turns out to be very fast now, the standards committee will be pl= aying catch-up with other libraries forever. (and even if it is the fastest= , the people who care about speed (game developers) are going to implement = their own library anyway) Instead it should be recognized that if you write= a library for the standard, you have got a whole different set of opportun= ities. The main one being that you could define the interface that most 2D = drawing will follow in C++. My ideal standard 2D library would be one about= which I could say "if you implement your drawing in this, it won't be the = fastest, but it will be fast enough in almost all cases, and Qt has a compa= tibility layer that will make your code work in all Qt applications. And so= does GTK+. And so does SDL. So unless performance is super important to yo= u, just use this." (that being said performance should not be ignored and I= would much prefer abstractions which are almost free like those used in &l= t;random> as opposed to those used in iostreams)

Cheers,

M= alte

On Monday, January 27, 2014 7:16:14 PM UTC-5, Michael McLaughli= n wrote:
= I'm in the process of providing more detailed answers because the I appreci= ate the earlier feedback and feel that it is helpful. As suc= h I think each post deserve a detailed response.
<= div> 
But I just wanted to pause to say that I think that Thiago's post= is a excellent summary of things as they stand going in to Issaquah.<= /div>
 
Elsewhere, in a humorous context, I summarized i= t as follows: If N3888 were incorporated into the Standard as-is,= I would feel compelled to request that the Issaquah Police Department inve= stigate the possibility that we had all been unknowingly exposed to some su= bstance with psychotropic properties. :)
 
-Mike
 

On Mon, Jan 27, 2014 at 7:01 PM, Thiago Macieira <thi...@macieira.org<= /a>> wrote:
On segunda-feira, 27 de janeiro de 2014 18:06:49, Felipe M= agno de Almeida
wrote:
> > I'm arguing that we need an efficient C++ library more than = we need a
> > generic one. So I'm arguing to *first* get what matters, and then=
> > generalise.
> If what you mean by first is that it is included to the C++ standard > library, then
> I would be against. Not that I can vote :). If you meant someone writi= ng a
> new C++ library, then I'm always for it. The more the merrier, of cour= se.

That's partially what I meant. In my opinion, having a library that c= annot
possibly do ARGB32 efficiently is a disservice to C++ developers, even if i= t can
also do ARGB48, ARGB64, RGB565, YUV420, HSV, and other crazy pixel formats.=

I meant that we first need to figure out the API, we need to get started somewhere. Let's figure out what we need, how it would work, and how it can= be
implemented efficiently. Without a reference implementation that passes bas= ic
quality check, we'll get nowhere. This is why the current proposal is based= on
Cairo: it implements today's technology efficiently, even if the API is not= very
C++-like yet.

After we get that, we can study generalisations without compromising the quality. Once that is done, it can be proposed to the standard.

We're still trying to get step 1 done.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 535= 8

--

---
You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposal...@isocpp.or= g.
To post to this group, send email to s= td-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposal= s/.

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_4170_19733406.1390881006608-- .