220 28760 <494491f9-ad74-4381-8b45-bae292d2d959@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: GUI Date: Wed, 12 Oct 2016 13:30:27 -0700 (PDT) Lines: 151 Approved: news@gmane.org Message-ID: <494491f9-ad74-4381-8b45-bae292d2d959@isocpp.org> References: <8e7ef2a9-cc07-41bf-b802-6e7ea795f880@isocpp.org> <6179833.5EeAZCx2QF@tjmaciei-mobl1> <15067047.jHVJzqrvNu@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1918_1671072731.1476304228304" X-Trace: blaine.gmane.org 1476304248 8635 195.159.176.226 (12 Oct 2016 20:30:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Oct 2016 20:30:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCDODCNR2QPRBZN27K7QKGQECQIUVXI@isocpp.org Wed Oct 12 22:30:43 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f197.google.com ([209.85.216.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buQAY-0008LR-0Q for gclcip-std-proposals@m.gmane.org; Wed, 12 Oct 2016 22:30:31 +0200 Original-Received: by mail-qt0-f197.google.com with SMTP id m5sf42308486qtb.3 for ; Wed, 12 Oct 2016 13:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=i6v6Ximl/z9v5FywIN798Br46uEVb3P9RPf2/HkFE24=; b=Ypj8NTcqyOjjl8vHBmhyhql9HbKUL/Arg/G3n2OsY6mkeGfVAdDGjUc45HjbjNtOb1 o2noWFtuHCmR8CareXfeF/enYx+eo3QBrCGt7KFJ2c7ERgzQHfkXE6vKfPFT9+tIwCjf O0HE+PZWL8qLS8FYEHKIjhNaYUKw7p8Jt3TduWixA1fbxmY5Fht3KWPrp+bSEr/I5u6e LfrdZ57qItnxW579MDbs3JHswO9gJ7UiXqNLpC20dHrUYgScdzoLATr5K8tluu8t6nQt EDvpbWJyZGb1dzpk0U92gpdZ2eEhBRzTCnjU6+Gd2+zPkmoKkkHR7KCXztpBO7nUe42a nyIw== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=i6v6Ximl/z9v5FywIN798Br46uEVb3P9RPf2/HkFE24=; b=JlYWm7ekdpeAqWovWDUXWzLxl9MTw1OHXJ0XIUAdYnyORe4tmkhWNjShMMnK0wO7+2 c11ikUTU/27VmNao99J3Y7ugSb5g7+hZVq56krgCmpjJSvITgg+HwkL3hQoIkTRfkDHV cU8xn2YaBzfN2nnMfImSSV4C3s1tqq/rV8bniwzvaYGngz5w94tMT1Ri0iduwPchcdUo Z4gIs4wOIVdHE32FqG/FMB2T6rsiFG7Q8RKTKTTX7IN2161XnDuxu/LC4dbpFSKP3T9m 7QW5tmufLwyqeKXsHbWPqdS5jAFNcUI0floYEUWPigoPCL3bYLpfvvgmUQmkACEsT0dE 9PRw== 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=i6v6Ximl/z9v5FywIN798Br46uEVb3P9RPf2/HkFE24=; b=DtfibFIin08A+dTmlx+ZpfffZK+7oVw/OB2WdX8RPsyoXaOwxTYn3YfrOoE3Owv5Gp LnF4zryvwdEpu51zER2Cqf7O64HGeSrMuTjMYpzkgpW+sdjbdsVeNzR3p1zuoXS9Uzlq YzVxoQz17gzYFORTOXsTAVuHGtk6i1w5uFZ1sf6AxRAd6tLfapiNdZ2JCxf64CO/70GO EUyTpNiolukUFwfAg6++anvL4Kzw9cbfLAUNUi/3X1wPilQuFHZZ8YdJo/OkmoJPL5Qs vb97qjjz8ve52dnjO2TNetUBfmu9+FZPUhMQhKvhPeHqDK1ivMJrHjDtOZpWIDR3NRET Yksg== X-Gm-Message-State: AA6/9RlkoKbz5kLQ2n4HqootnbQrLEckG1p5K6QeHVzBJIyMG20Y02nJfqjr2q9jRRBtUg== X-Received: by 10.200.33.233 with SMTP id 38mr795891qtz.13.1476304231872; Wed, 12 Oct 2016 13:30:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.10.13 with SMTP id 13ls1963389itw.16.gmail; Wed, 12 Oct 2016 13:30:29 -0700 (PDT) X-Received: by 10.36.190.137 with SMTP id i131mr337907itf.8.1476304229236; Wed, 12 Oct 2016 13:30:29 -0700 (PDT) In-Reply-To: X-Original-Sender: Sean.Middleditch@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:28760 Archived-At: ------=_Part_1918_1671072731.1476304228304 Content-Type: multipart/alternative; boundary="----=_Part_1919_1580363307.1476304228304" ------=_Part_1919_1580363307.1476304228304 Content-Type: text/plain; charset=UTF-8 On Wednesday, October 12, 2016 at 8:21:24 AM UTC-7, Ville Voutilainen wrote: > > > Cairo HW-accelerates that part, so why wouldn't this library they are > proposing, since it's based > on Cairo? > This was a point I was trying to make to that working group. Cairo is super sub-optimal. Every major vendor who started using Ciaro dropped it and replaced it with a better library, often having to home-grow their own. Cairo is a stateful/contextful library built around GL-like models of programming. Which isn't how hardware works, nor how drivers work, nor even how good software works. Good canvas drawing libraries operate in as stateless a fashion a possible. This is both about speed and interface design. Stateful interfaces like Cairo/GL require a huge amount of work in the library to bounce state changes and optimize around call patterns that the user is forced to write sub-optimally due to the composition problem. The composition problem results in different pieces of code not being able to cooperate seamlessly. Hand off a Cairo canvas to a helper routine/library and you have no idea what state may be changed out from under you. So to avoid surprise bugs you have to do a full state save/restore. Which is expensive when you don't need it. So the library has to do a ton of work to de-bounce unnecessary state changes that the library itself is forcing users to make for correctness. And that's assuming that users remember to do all the extra steps to achieve said correctness and don't just get all the bugs. Basing a modern canvas library that will be standardized in 2020+ off of Cairo would be a baffingly poor decision. It was an out-dated model of graphics programming 5 years ago and isn't going to be any less antiquated 4 years from now. It will be difficult to use and it will be inefficient, thus solving few real use cases; beginners or quick uses need easy and pros need efficient. I don't even want to get into the GUI parts. You claimed earlier that GUIs don't change that often, which is just outright wrong. You can't go a week without Apple or Facebook or Google or Microsoft or Twitter or Uber or whoever releasing a new library in this domain. The C++ community talking about standardizing widgets and MVC while the folks who write most of the GUIs we actually use day-to-day are off in functional-reactive land shipping efficient component-based stateless reactive UIs. Let's not even get into how "C++" UIs are transitioning to doing everything in HTML5, QML, XAML, or so on with barely any C++ even in the application UI code. Putting Cairo into the stdlib makes barely more sense than putting 3dfx Glide into the stdlib, IMO. :) We just need a package manager. The problem with third party libraries isn't fundamentally that they're not in the standard; the problem is that using non-standard libraries involves steps that vary wildly by compiler and environment. Rather than pulling individual libraries one-by-one into the standard and signing up to maintain them in perpetuity, fix the fundamental root problem. Then folks who decide they want C++ Cairo can just import cairomm and be done with it. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/494491f9-ad74-4381-8b45-bae292d2d959%40isocpp.org. ------=_Part_1919_1580363307.1476304228304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, October 12, 2016 at 8:21:24 AM UTC-7, Ville = Voutilainen wrote:

Cairo HW= -accelerates that part, so why wouldn't this library they are
proposing, since it's based
on Cairo?

This was a point I was trying to make = to that working group. Cairo is super sub-optimal. Every major vendor who s= tarted using Ciaro dropped it and replaced it with a better library, often = having to home-grow their own.

Cairo is a stateful= /contextful library built around GL-like models of programming. Which isn&#= 39;t how hardware works, nor how drivers work, nor even how good software w= orks. Good canvas drawing libraries operate in as stateless a fashion a pos= sible.

This is both about speed and interface desi= gn. Stateful interfaces like Cairo/GL require a huge amount of work in the = library to bounce state changes and optimize around call patterns that the = user is forced to write sub-optimally due to the composition problem.
=

The composition problem results in different pieces of = code not being able to cooperate seamlessly. Hand off a Cairo canvas to a h= elper routine/library and you have no idea what state may be changed out fr= om under you. So to avoid surprise bugs you have to do a full state save/re= store. Which is expensive when you don't need it. So the library has to= do a ton of work to de-bounce unnecessary state changes that the library i= tself is forcing users to make for correctness. And that's assuming tha= t users remember to do all the extra steps to achieve said correctness and = don't just get all the bugs.

Basing a modern c= anvas library that will be standardized in 2020+ off of Cairo would be a ba= ffingly poor decision. It was an out-dated model of graphics programming 5 = years ago and isn't going to be any less antiquated 4 years from now. I= t will be difficult to use and it will be inefficient, thus solving few rea= l use cases; beginners or quick uses need easy and pros need efficient.


I don't even want to get into the = GUI parts. You claimed earlier that GUIs don't change that often, which= is just outright wrong. You can't go a week without Apple or Facebook = or Google or Microsoft or Twitter or Uber or whoever releasing a new librar= y in this domain. The C++ community talking about standardizing widgets and= MVC while the folks who write most of the GUIs we actually use day-to-day = are off in functional-reactive land shipping efficient component-based stat= eless reactive UIs. Let's not even get into how "C++" UIs are= transitioning to doing everything in HTML5, QML, XAML, or so on with barel= y any C++ even in the application UI code.


Putting Cairo into the stdlib makes barely more sense than putting = 3dfx Glide into the stdlib, IMO. :)


=
We just need a package manager. The problem with third party libraries= isn't fundamentally that they're not in the standard; the problem = is that using non-standard libraries involves steps that vary wildly by com= piler and environment. Rather than pulling individual libraries one-by-one = into the standard and signing up to maintain them in perpetuity, fix the fu= ndamental root problem. Then folks who decide they want C++ Cairo can just = import cairomm and be done with it.

--
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/494491f9-ad74-4381-8b45-bae292d2d959= %40isocpp.org.
------=_Part_1919_1580363307.1476304228304-- ------=_Part_1918_1671072731.1476304228304-- .