------=_Part_1_2027479.1390359662520
Content-Type: text/plain; charset=UTF-8

Hello everyone.

I have been taking a look at http://isocpp.org/files/papers/N3888.pdf

Cairo is an object oriented API. No c++ standard library component except
iostreams is object-oriented.

The current proposal proposes this:

    auto x1 = some_object();

    //Silently aliases x1
    auto x2 = x1;


I think this approach won't be satisfactory, since it violates the usual
semantics for c++ objects, at least in the standard library.

I see that random_access_iterators vs bidirectional operators provide
operator +=.

Random_access_iterator -> operator+=
Bidirectional_iterator       -> std::advance  --- Named function since it
is expensive.

I have more proposals on how to handle values for the library.

1. Disable copy with copy constructor, since it's expensive,
Provide:
    copy() method for deep copy.

class Texture {
public:
    Texture & operator=(Texture const &) = delete;
    Texture(Texture const &) = delete;

    //Movable

    Texture copy() const;
private:
   native_object obj;
};

Advantages:

- Well known semantics.
- No need for synchronization. When wanting a reference, you use a true
reference to the object or
a pointer, so you know you are aliasing.
- Avoids copy accidents.

Disadvantage:

- Not reference counted anymore means taking care of lifetime by yourself.


2. Disable copy with copy constructor, since it's expensive.
Provide:
    1.- copy() method for deep copy.
    2.- share() method for sharing the native object.

class Texture {
public:
    Texture & operator=(Texture const &) = delete;
    Texture(Texture const &) = delete;

    //Movable

    Texture copy() const;
    Texture share() const;
private:
    //Reference-counted object
    shared_ptr<native_object> obj;
};

Advantages:

- Well known semantics.

Disadvantage:

- You can still alias objects, though aliasing is more explicit since you
need a call to share().

3.- Differentiate between mutable and const objects? (Just idea, didn't
think too much about this yet)

In this case Const objects CANNOT point to mutable objects:

//Mutable
class Texture {
public:
  //Movable but NOT copyable.

  Texture copy() const;
  ConstTexture const_copy() const;

   //No share() method, make a const_copy first.
private:
  native_object obj;
};


//Immutable guaranteed
class ConstTexture {
 //Movable and copyable

   Texture muable_copy() const;
private:
  shared_ptr<native_object> obj;
};

1.- Const objects are freely copyable.
2.- Non-const objects must be explicitely copied.

Here my 2 cents. :D
I think we shouldn't allow implicit sharing, at least, since this is bad
for multithreaded code in general.


--

---
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_1_2027479.1390359662520
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello everyone.<div><br></div><div>I have been taking a lo=
ok at&nbsp;http://isocpp.org/files/papers/N3888.pdf</div><div><br></div><di=
v>Cairo is an object oriented API. No c++ standard library component except=
 iostreams is object-oriented.</div><div><br></div><div>The current proposa=
l proposes this:</div><div><br></div><div>&nbsp; &nbsp; auto x1 =3D some_ob=
ject();</div><div><br></div><div>&nbsp; &nbsp; //Silently aliases x1&nbsp;<=
/div><div>&nbsp; &nbsp; auto x2 =3D x1;</div><div><br></div><div><br></div>=
<div>I think this approach won't be satisfactory, since it violates the usu=
al semantics for c++ objects, at least in the standard library.</div><div><=
br></div><div>I see that random_access_iterators vs bidirectional operators=
 provide operator +=3D.</div><div><br></div><div>Random_access_iterator -&g=
t; operator+=3D</div><div>Bidirectional_iterator &nbsp; &nbsp; &nbsp; -&gt;=
 std::advance &nbsp;--- Named function since it is expensive.</div><div><br=
></div><div>I have more proposals on how to handle values for the library.<=
/div><div><br></div><div>1. Disable copy with copy constructor, since it's =
expensive,&nbsp;</div><div>Provide:</div><div>&nbsp; &nbsp; copy() method f=
or deep copy.</div><div><br></div><div><div>class Texture {</div><div>publi=
c:</div><div>&nbsp; &nbsp; Texture &amp; operator=3D(Texture const &amp;) =
=3D delete;</div><div>&nbsp; &nbsp; Texture(Texture const &amp;) =3D delete=
;</div><div><br></div><div>&nbsp; &nbsp; //Movable</div><div><br></div><div=
>&nbsp; &nbsp; Texture copy() const;</div><div>private:<br></div><div>&nbsp=
; &nbsp;native_object obj;</div><div>};</div></div><div><br></div><div>Adva=
ntages:</div><div><br></div><div>- Well known semantics.</div><div>- No nee=
d for synchronization. When wanting a reference, you use a true reference t=
o the object or</div><div>a pointer, so you know you are aliasing.</div><di=
v>- Avoids copy accidents.</div><div><br></div><div>Disadvantage:</div><div=
><br></div><div>- Not reference counted anymore means taking care of lifeti=
me by yourself.<br></div><div><br></div><div><br></div><div><div>2. Disable=
 copy with copy constructor, since it's expensive.</div><div>Provide:</div>=
<div>&nbsp; &nbsp; 1.- copy() method for deep copy.</div><div>&nbsp; &nbsp;=
 2.- share() method for sharing the native object.</div><div><br></div></di=
v><div><div>class Texture {</div><div>public:</div><div>&nbsp; &nbsp; Textu=
re &amp; operator=3D(Texture const &amp;) =3D delete;</div><div>&nbsp; &nbs=
p; Texture(Texture const &amp;) =3D delete;</div><div><br></div><div>&nbsp;=
 &nbsp; //Movable</div><div><br></div><div>&nbsp; &nbsp; Texture copy() con=
st;</div><div>&nbsp; &nbsp; Texture share() const;</div><div>private:<br></=
div><div>&nbsp; &nbsp; //Reference-counted object</div><div>&nbsp; &nbsp; s=
hared_ptr&lt;native_object&gt; obj;</div><div>};</div></div><div><br></div>=
<div><div>Advantages:</div><div><br></div><div>- Well known semantics.</div=
><div><br></div><div>Disadvantage:</div><div><br></div><div>- You can still=
 alias objects, though aliasing is more explicit since you need a call to s=
hare().</div></div><div><br></div><div>3.- Differentiate between mutable an=
d const objects? (Just idea, didn't think too much about this yet)</div><di=
v><br></div><div>In this case Const objects CANNOT point to mutable objects=
:</div><div><br></div><div>//Mutable</div><div>class Texture {</div><div>pu=
blic:</div><div>&nbsp; //Movable but NOT copyable.</div><div><br></div><div=
>&nbsp; Texture copy() const;</div><div>&nbsp; ConstTexture const_copy() co=
nst;</div><div><br></div><div>&nbsp; &nbsp;//No share() method, make a cons=
t_copy first.</div><div>private:</div><div>&nbsp; native_object obj;</div><=
div>};</div><div><br></div><div><br></div><div>//Immutable guaranteed</div>=
<div>class ConstTexture {</div><div>&nbsp;//Movable and copyable</div><div>=
<br></div><div>&nbsp; &nbsp;Texture muable_copy() const;</div><div>private:=
</div><div>&nbsp; shared_ptr&lt;native_object&gt; obj; &nbsp;</div><div>};<=
/div><div><br></div><div>1.- Const objects are freely copyable.</div><div>2=
..- Non-const objects must be explicitely copied.</div><div><br></div><div>H=
ere my 2 cents. :D&nbsp;</div><div>I think we shouldn't allow implicit shar=
ing, at least, since this is bad for multithreaded code in general.</div><d=
iv><br></div><div><br></div></div>

<p></p>

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

------=_Part_1_2027479.1390359662520--

.

------=_Part_9_12230387.1390473843319
Content-Type: text/plain; charset=UTF-8

On Wednesday, 22 January 2014 03:01:02 UTC, germa...@gmail.com wrote:
>
> I have been taking a look at http://isocpp.org/files/papers/N3888.pdf
> The current proposal proposes this:
>
>     auto x1 = some_object();
>     //Silently aliases x1
>     auto x2 = x1;
>
> I think this approach won't be satisfactory, since it violates the usual
> semantics for c++ objects, at least in the standard library.
>

I agree; the paper proposes an alternative reference semantics using the
existing unique_ptr and shared_ptr.  This would allow:

    unique_ptr<surface> surf = make_surface(...);
    unique_ptr<context> ctx = make_context(*surf, ...);

Alternatively, make_surface() could be written surface::make() etc. The
copy constructors and assignment operators would be deleted; constructors
would be private.

Sharing would be via shared_ptr<>, which could be specialised to use the
underlying C library's reference counting.

This would make the aliasing semantics explicit, and do so using standard
vocabulary types (unique_ptr and shared_ptr).  Users (even beginners) can
be expected to know and understand these types. The syntactic cost (over
shared ownership semantics) is minimal: indirection for method calls. Most
code would of course use auto instead of writing unique_ptr explicitly.

--

---
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_9_12230387.1390473843319
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, 22 January 2014 03:01:02 UTC, germa...@gmail=
..com  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>I have been taking a look at&nbsp;<a href=3D"http://isocpp.org/files/pa=
pers/N3888.pdf" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.go=
ogle.com/url?q\75http%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN3888.pdf\46sa\=
75D\46sntz\0751\46usg\75AFQjCNF85XkO6JdpXlG8pRHM7NzTOJpO4g';return true;" o=
nclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fisocpp.or=
g%2Ffiles%2Fpapers%2FN3888.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNF85XkO6Jd=
pXlG8pRHM7NzTOJpO4g';return true;">http://isocpp.org/files/<wbr>papers/N388=
8.pdf</a><br></div><div>The current proposal proposes this:<br></div><div><=
br></div><div>&nbsp; &nbsp; auto x1 =3D some_object();</div><div>&nbsp; &nb=
sp; //Silently aliases x1&nbsp;<br></div><div>&nbsp; &nbsp; auto x2 =3D x1;=
</div><div><br></div><div>I think this approach won't be satisfactory, sinc=
e it violates the usual semantics for c++ objects, at least in the standard=
 library.</div></div></blockquote><div><br></div><div>I agree; the paper pr=
oposes an alternative reference semantics using the existing unique_ptr and=
 shared_ptr. &nbsp;This would allow:</div><div><br></div><div>&nbsp; &nbsp;=
 unique_ptr&lt;surface&gt; surf =3D make_surface(...);</div><div>&nbsp; &nb=
sp; unique_ptr&lt;context&gt; ctx =3D make_context(*surf, ...);</div><div><=
br></div><div>Alternatively, make_surface() could be written surface::make(=
) etc. The copy constructors and assignment operators would be deleted; con=
structors would be private.</div><div><br></div><div>Sharing would be via s=
hared_ptr&lt;&gt;, which could be specialised to use the underlying C libra=
ry's reference counting.</div><div><br></div><div>This would make the alias=
ing semantics explicit, and do so using standard vocabulary types (unique_p=
tr and shared_ptr). &nbsp;Users (even beginners) can be expected to know an=
d understand these types. The syntactic cost (over shared ownership semanti=
cs) is minimal: indirection for method calls. Most code would of course use=
 auto instead of writing unique_ptr explicitly.</div></div>

<p></p>

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

------=_Part_9_12230387.1390473843319--

.

On Thu, Jan 23, 2014 at 11:44 AM, Edward Catmur <ed@catmur.co.uk> wrote:
> On Wednesday, 22 January 2014 03:01:02 UTC, germa...@gmail.com wrote:
>>
>> I have been taking a look at http://isocpp.org/files/papers/N3888.pdf
>> The current proposal proposes this:
>>
>>     auto x1 = some_object();
>>     //Silently aliases x1
>>     auto x2 = x1;
>>
>> I think this approach won't be satisfactory, since it violates the usual
>> semantics for c++ objects, at least in the standard library.

Well, there is std::shared_ptr.

> I agree; the paper proposes an alternative reference semantics using the
> existing unique_ptr and shared_ptr.  This would allow:
>
>     unique_ptr<surface> surf = make_surface(...);
>     unique_ptr<context> ctx = make_context(*surf, ...);
>
> Alternatively, make_surface() could be written surface::make() etc. The copy
> constructors and assignment operators would be deleted; constructors would
> be private.

The deleter type of a unique_ptr is not type-erased. This could be a
problem especially if other kinds of resources are involved (like GPU
resources).

--

---
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/.

.

--001a11c2f5eae8bf9a04f0c815b9
Content-Type: text/plain; charset=UTF-8

This is a post in two parts. The first is an announcement and the second is
a first attempt at a reply to all the great feedback in this thread.

The reference implementation of N3888 is now posted to GitHub:
https://github.com/mikebmcl/N3888_RefImpl . It currently requires Windows
(tested on 7 and 8.1) with Visual Studio 2013 (the free Visual Studio 2013
Express for Windows Desktop works fine).

I'm hoping we will have a GNU/Linux X11-based (or maybe XCB-based) build
using GCC sometime in the near future but I can't make any promises. (The
code is mostly standard, portable C++ with only a handful of
Windows-specific things, most of which relate to the entry point and
creating a window. So it's almost entirely a matter of finding the time to
create a project file system using CMake or Autotools. The past few days
have been pretty quiet and thus productive but now with the reference
implementation rolling out there could be a lot of feedback, questions, and
concerns that need attention. So we'll see. It shouldn't be difficult to do
a quick and dirty port if you want to try it out on a different platform).

Also, I can't promise there are no bugs. I've found and squashed several
this week but there may be more lurking which will show up when I have a
chance to really test the functionality.

Thanks!

(p.s. Apologies to those who read this in multiple places since I am
copying and pasting the same release message because I'm exhausted and want
to get to sleep!)

p.p.s. - Since I haven't had a chance to properly respond to this thread
yet, I decided to take this opportunity (tiredness notwithstanding). I've
tried to address the main points but this is all really good feedback so I
need to re-read it when I'm fresh and consider it more carefully and
thoroughly. So I offer my apologies in advance if in my response below I
have missed anything or failed to properly and completely address something.

Hi! Thanks for all the great feedback so far. Sorry I'm so late replying to
this thread. The decision to go with shared_ptr-style shared ownership
semantics was difficult. My co-authors are likely to have different
opinions on the topic so I can only speak for myself. To me, shared
ownership semantics produces cleaner looking code than move-only semantics
would. It's not an unknown type of semantics in the standard library, just
uncommon (only shared_ptr and shared_mutex currently uses it).

To me the question is whether the committee is willing to more broadly
accept shared ownership semantics and if so under what conditions. The
types could all be prefixed with shared_ to keep with the naming convention
of other shared ownership types. But the concerns may run deeper than
just naming. I'm going to do my best to be able to provide a very good case
for shared ownership semantics in Issaquah. I appreciate all the insightful
comments as they are helping me to clarify my thinking and better
understand the concerns that people will have on this issue.

There is also the issue of threading. It is something I need to give more
thought to. Graphics programming is typically single threaded (or the
graphics portion is anyway; ancillary operations can be and often are
placed on separate threads). The reason for this is that to maintain smooth
animations the program generally needs a frame rate of at least 30 frames
per second. Because of how massively parallel modern GPUs are, stalling
them in any way can be very expensive. So blocking a program's rendering
thread is generally unacceptable unless it is unavoidable. Multithreading
graphics using something such as a mutex for synchronization would
generally be a bad idea for most non-trivial applications. D3D 11 and
OpenGL both have paradigms for multithreading that generally avoid the need
for blocking synchronization on the main rendering thread. Cairo is able to
use a strategy that is similar to that used with OpenGL (in brief, each
ancillary thread gets its own contexts with their own surfaces to which
components of a scene are rendered; the main rendering thread concatenates
the resulting components together while caching previously rendered data
for reuse in the event that a thread is not ready with new data when the
main thread requires it. In this way the main thread uses synchronization
but does not block waiting on child threads). Nonetheless I will be
spending additional time considering the implications of 17.6.5.9
[res.on.data.races] in relation to these types since exceptions cannot
necessarily be made simply because of typical usage patterns and best
practices.

Thank you for your time.

Respectfully yours,

Michael B. McLaughlin


On Tue, Jan 21, 2014 at 10:01 PM, <germandiago@gmail.com> wrote:

> Hello everyone.
>
> I have been taking a look at http://isocpp.org/files/papers/N3888.pdf
>
> Cairo is an object oriented API. No c++ standard library component except
> iostreams is object-oriented.
>
> The current proposal proposes this:
>
>     auto x1 = some_object();
>
>     //Silently aliases x1
>     auto x2 = x1;
>
>
> I think this approach won't be satisfactory, since it violates the usual
> semantics for c++ objects, at least in the standard library.
>
> I see that random_access_iterators vs bidirectional operators provide
> operator +=.
>
> Random_access_iterator -> operator+=
> Bidirectional_iterator       -> std::advance  --- Named function since it
> is expensive.
>
> I have more proposals on how to handle values for the library.
>
> 1. Disable copy with copy constructor, since it's expensive,
> Provide:
>     copy() method for deep copy.
>
> class Texture {
> public:
>     Texture & operator=(Texture const &) = delete;
>     Texture(Texture const &) = delete;
>
>     //Movable
>
>     Texture copy() const;
> private:
>    native_object obj;
> };
>
> Advantages:
>
> - Well known semantics.
> - No need for synchronization. When wanting a reference, you use a true
> reference to the object or
> a pointer, so you know you are aliasing.
> - Avoids copy accidents.
>
> Disadvantage:
>
> - Not reference counted anymore means taking care of lifetime by yourself.
>
>
> 2. Disable copy with copy constructor, since it's expensive.
> Provide:
>     1.- copy() method for deep copy.
>     2.- share() method for sharing the native object.
>
> class Texture {
> public:
>     Texture & operator=(Texture const &) = delete;
>     Texture(Texture const &) = delete;
>
>     //Movable
>
>     Texture copy() const;
>     Texture share() const;
> private:
>     //Reference-counted object
>     shared_ptr<native_object> obj;
> };
>
> Advantages:
>
> - Well known semantics.
>
> Disadvantage:
>
> - You can still alias objects, though aliasing is more explicit since you
> need a call to share().
>
> 3.- Differentiate between mutable and const objects? (Just idea, didn't
> think too much about this yet)
>
> In this case Const objects CANNOT point to mutable objects:
>
> //Mutable
> class Texture {
> public:
>   //Movable but NOT copyable.
>
>   Texture copy() const;
>   ConstTexture const_copy() const;
>
>    //No share() method, make a const_copy first.
> private:
>   native_object obj;
> };
>
>
> //Immutable guaranteed
> class ConstTexture {
>  //Movable and copyable
>
>    Texture muable_copy() const;
> private:
>   shared_ptr<native_object> obj;
> };
>
> 1.- Const objects are freely copyable.
> 2.- Non-const objects must be explicitely copied.
>
> Here my 2 cents. :D
> I think we shouldn't allow implicit sharing, at least, since this is bad
> for multithreaded code in general.
>
>
>  --
>
> ---
> 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/.
>

--

---
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/.

--001a11c2f5eae8bf9a04f0c815b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>This is a post in two parts. The first is an ann=
ouncement and the second is a first attempt at a reply to all the great fee=
dback in this thread.</div><div>=C2=A0</div><div>The reference implementati=
on of N3888 is now posted to GitHub: <a href=3D"https://github.com/mikebmcl=
/N3888_RefImpl" target=3D"_blank">https://github.com/mikebmcl/N3888_RefImpl=
</a> . It currently requires Windows (tested on 7 and 8.1) with Visual Stud=
io 2013 (the free Visual Studio 2013 Express for Windows Desktop works fine=
).</div>
<div>=C2=A0</div><div>I&#39;m hoping we will have a GNU/Linux X11-based (or=
 maybe XCB-based)=C2=A0build using GCC sometime in the near future but I ca=
n&#39;t make any promises. (The code is mostly standard, portable C++ with =
only a handful of Windows-specific things, most of which relate to the entr=
y point and creating a window. So it&#39;s almost entirely a matter of find=
ing the time to create a project file system using CMake or Autotools. The =
past few days have been pretty quiet and thus=C2=A0productive but now with =
the reference implementation rolling out there could be a lot of feedback, =
questions, and concerns that need attention. So we&#39;ll see. It shouldn&#=
39;t be difficult to do a quick and dirty port if you want to try it out on=
 a different platform).</div>
<div>=C2=A0</div><div>Also, I can&#39;t promise there are no bugs. I&#39;ve=
 found and squashed several this week but there may be more lurking which w=
ill show up when I have a chance to really test the functionality.</div><di=
v>
=C2=A0</div><div>Thanks!</div><div>=C2=A0</div><div>(p.s. Apologies to thos=
e who read this in multiple places since I am copying and pasting=C2=A0the =
same release message=C2=A0because I&#39;m exhausted and want to get to slee=
p!)</div><div>=C2=A0</div>
<div>p.p.s. - Since I haven&#39;t had a chance to properly respond to this =
thread yet, I decided to take this opportunity (tiredness notwithstanding).=
 I&#39;ve tried to address the main points but this is all really good feed=
back so I need to re-read it when I&#39;m fresh and consider it more carefu=
lly and thoroughly. So I offer my=C2=A0apologies in advance=C2=A0if in my r=
esponse below I have missed anything=C2=A0or failed to properly and complet=
ely address something.</div>
<div>=C2=A0<br clear=3D"all"></div><div class=3D"gmail_extra"><div></div></=
div></div><div>Hi! Thanks for all the great feedback so far. Sorry I&#39;m =
so late replying to this thread. The decision to go with shared_ptr-style s=
hared ownership semantics was difficult. My co-authors are likely to have d=
ifferent opinions on the topic so I can only speak for myself. To me, share=
d ownership semantics produces cleaner looking code than move-only semantic=
s would. It&#39;s not an unknown type of semantics in the standard library,=
 just uncommon (only shared_ptr and shared_mutex currently uses it).</div>
<div>=C2=A0</div><div>To me the question is whether the committee is willin=
g to more=C2=A0broadly accept shared ownership semantics and if so under wh=
at conditions.=C2=A0The types could all be prefixed with shared_ to keep wi=
th the naming convention of other shared ownership types. But the concerns =
may run deeper than just=C2=A0naming.=C2=A0I&#39;m going to do my best to b=
e able to=C2=A0provide a very good case for shared ownership semantics=C2=
=A0in Issaquah. I appreciate all the insightful comments as they are helpin=
g me to clarify my thinking and better understand the concerns that people =
will have on this issue.</div>
<div>=C2=A0</div><div>There is also the issue of threading. It is something=
 I need to give more thought to. Graphics programming is typically single t=
hreaded (or the graphics portion is anyway; ancillary operations can be and=
 often are placed on separate threads). The reason for this is that to main=
tain smooth animations the program generally needs=C2=A0a frame rate of=C2=
=A0at least 30 frames per second. Because of how massively parallel modern =
GPUs are, stalling them in any way=C2=A0can be=C2=A0very expensive. So bloc=
king a program&#39;s rendering thread is generally unacceptable unless it i=
s unavoidable. Multithreading graphics using something=C2=A0such as=C2=A0a =
mutex for synchronization would generally be a bad idea for most non-trivia=
l applications. D3D 11=C2=A0and OpenGL both have paradigms for multithreadi=
ng that generally avoid the need for blocking synchronization on the main r=
endering thread. Cairo is able to use a strategy that is similar to that us=
ed with OpenGL (in brief, each ancillary thread gets its own contexts with =
their own surfaces to which components of a scene are rendered; the main re=
ndering thread concatenates the resulting components together while caching=
 previously rendered data for reuse in the event that a thread is not ready=
 with new data when the main thread requires it.=C2=A0In this way=C2=A0the =
main thread uses synchronization but does not block waiting on child thread=
s). Nonetheless I will be spending additional time considering the implicat=
ions of 17.6.5.9 [res.on.data.races] in relation to these types since excep=
tions cannot necessarily be made simply because of typical usage patterns a=
nd best practices.</div>
<div>=C2=A0</div><div>Thank you for your time.</div><div>=C2=A0</div><div>R=
espectfully yours,</div><div>=C2=A0<br clear=3D"all"></div><div class=3D"gm=
ail_extra"><div><div>Michael B. McLaughlin</div></div>=C2=A0<br><br><div cl=
ass=3D"gmail_quote">On Tue, Jan 21, 2014 at 10:01 PM,  <span dir=3D"ltr">&l=
t;<a href=3D"mailto:germandiago@gmail.com" target=3D"_blank">germandiago@gm=
ail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">Hello everyone.<div><br></div><div>I have=
 been taking a look at=C2=A0<a href=3D"http://isocpp.org/files/papers/N3888=
..pdf" target=3D"_blank">http://isocpp.org/files/papers/N3888.pdf</a></div>
<div><br></div><div>Cairo is an object oriented API. No c++ standard librar=
y component except iostreams is object-oriented.</div><div><br></div><div>T=
he current proposal proposes this:</div><div><br></div><div>=C2=A0 =C2=A0 a=
uto x1 =3D some_object();</div>
<div><br></div><div>=C2=A0 =C2=A0 //Silently aliases x1=C2=A0</div><div>=C2=
=A0 =C2=A0 auto x2 =3D x1;</div><div><br></div><div><br></div><div>I think =
this approach won&#39;t be satisfactory, since it violates the usual semant=
ics for c++ objects, at least in the standard library.</div>
<div><br></div><div>I see that random_access_iterators vs bidirectional ope=
rators provide operator +=3D.</div><div><br></div><div>Random_access_iterat=
or -&gt; operator+=3D</div><div>Bidirectional_iterator =C2=A0 =C2=A0 =C2=A0=
 -&gt; std::advance =C2=A0--- Named function since it is expensive.</div>
<div><br></div><div>I have more proposals on how to handle values for the l=
ibrary.</div><div><br></div><div>1. Disable copy with copy constructor, sin=
ce it&#39;s expensive,=C2=A0</div><div>Provide:</div><div>=C2=A0 =C2=A0 cop=
y() method for deep copy.</div>
<div><br></div><div><div>class Texture {</div><div>public:</div><div>=C2=A0=
 =C2=A0 Texture &amp; operator=3D(Texture const &amp;) =3D delete;</div><di=
v>=C2=A0 =C2=A0 Texture(Texture const &amp;) =3D delete;</div><div><br></di=
v><div>=C2=A0 =C2=A0 //Movable</div>
<div><br></div><div>=C2=A0 =C2=A0 Texture copy() const;</div><div>private:<=
br></div><div>=C2=A0 =C2=A0native_object obj;</div><div>};</div></div><div>=
<br></div><div>Advantages:</div><div><br></div><div>- Well known semantics.=
</div><div>- No need for synchronization. When wanting a reference, you use=
 a true reference to the object or</div>
<div>a pointer, so you know you are aliasing.</div><div>- Avoids copy accid=
ents.</div><div><br></div><div>Disadvantage:</div><div><br></div><div>- Not=
 reference counted anymore means taking care of lifetime by yourself.<br>
</div><div><br></div><div><br></div><div><div>2. Disable copy with copy con=
structor, since it&#39;s expensive.</div><div>Provide:</div><div>=C2=A0 =C2=
=A0 1.- copy() method for deep copy.</div><div>=C2=A0 =C2=A0 2.- share() me=
thod for sharing the native object.</div>
<div><br></div></div><div><div>class Texture {</div><div>public:</div><div>=
=C2=A0 =C2=A0 Texture &amp; operator=3D(Texture const &amp;) =3D delete;</d=
iv><div>=C2=A0 =C2=A0 Texture(Texture const &amp;) =3D delete;</div><div><b=
r></div><div>=C2=A0 =C2=A0 //Movable</div>
<div><br></div><div>=C2=A0 =C2=A0 Texture copy() const;</div><div>=C2=A0 =
=C2=A0 Texture share() const;</div><div>private:<br></div><div>=C2=A0 =C2=
=A0 //Reference-counted object</div><div>=C2=A0 =C2=A0 shared_ptr&lt;native=
_object&gt; obj;</div><div>};</div></div>
<div><br></div><div><div>Advantages:</div><div><br></div><div>- Well known =
semantics.</div><div><br></div><div>Disadvantage:</div><div><br></div><div>=
- You can still alias objects, though aliasing is more explicit since you n=
eed a call to share().</div>
</div><div><br></div><div>3.- Differentiate between mutable and const objec=
ts? (Just idea, didn&#39;t think too much about this yet)</div><div><br></d=
iv><div>In this case Const objects CANNOT point to mutable objects:</div>
<div><br></div><div>//Mutable</div><div>class Texture {</div><div>public:</=
div><div>=C2=A0 //Movable but NOT copyable.</div><div><br></div><div>=C2=A0=
 Texture copy() const;</div><div>=C2=A0 ConstTexture const_copy() const;</d=
iv><div><br>
</div><div>=C2=A0 =C2=A0//No share() method, make a const_copy first.</div>=
<div>private:</div><div>=C2=A0 native_object obj;</div><div>};</div><div><b=
r></div><div><br></div><div>//Immutable guaranteed</div><div>class ConstTex=
ture {</div>
<div>=C2=A0//Movable and copyable</div><div><br></div><div>=C2=A0 =C2=A0Tex=
ture muable_copy() const;</div><div>private:</div><div>=C2=A0 shared_ptr&lt=
;native_object&gt; obj; =C2=A0</div><div>};</div><div><br></div><div>1.- Co=
nst objects are freely copyable.</div>
<div>2.- Non-const objects must be explicitely copied.</div><div><br></div>=
<div>Here my 2 cents. :D=C2=A0</div><div>I think we shouldn&#39;t allow imp=
licit sharing, at least, since this is bad for multithreaded code in genera=
l.</div>
<span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div><br></di=
v></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

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

--001a11c2f5eae8bf9a04f0c815b9--

.

------=_Part_1650_32491777.1390768716669
Content-Type: text/plain; charset=UTF-8

Here are my comments. I understand that implementing these changes would in
some cases imply that it can't be implemented on top of Cairo, but I don't
think that could be a primary objective of a standardized API. I'm not
knowledgeable in Cairo but in other drawing APIs and to some extent the
underlying hardware. I think that it is more important to follow modern C++
paradigms is more important than simplicity of implementation. If we are
not even taking away the void* context handling which is really arcane we
can just as well use the original Cairo library, if you ask me. Also I
think that this library is modeled too closely on Win32 with its 80ties
style and today almost bizarre ideas of how to organize things. This is
definitely not something we want to perpetuate.

Here are detailed comments based on reading the synopsis. As the paper does
not go into detail I may have misunderstood some things, I apologize for
this already here:

The format enum seems a bit limited, as it does not contain for instance
3x12 bit RGB, which will be more and more used. Would it be possible to do
a struct again to get an open ended set of formats. This should also
contain the
subpixel_order information.

font_slant and font_weight: For instance wxWidgets provides more weight
values than normal and bold. Some even has a 0-100 percent weight and slant
in degrees. But maybe the enums only provide specific values on such a
gradual scale?

rectangle and rectangle_int should be replaced with a template, instances
of which are used in the api. This template along with point<T> should be
in the top level std namespace and used throughout std when appropriate.
Over time this will increase interoperability between 3rd party libraries
as they start using them.

Similarly matrix should be called something like transform_matrix and
inherit a generic std::matrix<2,3>, adding the affine transform specific
setup methods as indicated.

If the to me a little bizzare class recangle_list exists region should have
a ctor from it.

Is user_data_key and its use in device/surface really necessary to have?

Is shared_ptr semantics logical on device, really? It seems to me that
these are more in the vein of singletons (although there may be more than
one). That is, you get a handle to it from somewhere central, which you
then never actually copy.

The same goes for surface unless you can create subsurfaces as rects on a
parent surface, in which case reference counting is appropriate. However, I
think that the reference counting should only be used between such surface
objects, not for all "handles" to any one particular subwindow. This would
mean that there would be no copy constructors or assignment operators. The
ctor taking rect components is the one used to create a subsurface (and
doing the reference counting).

There should be a ctor of surface which takes a rectangle<double> to
describe the subsurface extent, not only one with four discrete ints. The
use of double in this API is strange to me, or needs to be complemented
with a (more commonly used) API using int. The latter solution would be
appropriate in the case that using double implies a coordinate transform
taking place before the subsurface is created. The hard thing about this is
that if rotation or shear is included in the transform the subwindow can
hardly be created.

get_font_options should return a const ref to the internal font_options
object. I suspect that this is really a property of the device, but maybe
not given recent GPU developments.

It seems that the fallback resolution handling would be more appropriately
placed in device.

mark_dirty_rectange shoud be available with a rectangle<int> as parameter.
It seems inconsistent that the subsurface creation ctor takes a double rect
and the dirty function takes a int rect.

Is dirty rect handling really a function in this API at all? It is tightly
connected to the windowing system event handling, while nothing else in
this API really is.

write_to_png seems as a strange function here, as it sets one file format
out in front of all others. Of course a image file read/write manager could
be added to "make file formats equal" but I would put this in the hands of
3rd party developers and instead concentrate on standardizing an in-memory
image memory class (placed in std or possibly its own sub-namespace, but
not in std::drawing at least).

The class image_surface seems to try to "be" this image memory, but only
for the limited application of drawing in it. This is really a pity as we
have lots of other application areas where image memories are important
entities.

vector<char> is a very unsuitable way to specify image data as it can't be
constructed without being inited to 0. There seems be great opposition
against allowing vectors to default-construct their elements, I have argued
for this many a time without any success. In the absense of a real image
memory class a char* + count API is actually much more appropriate as this
allowd image memories from other libraries to be used. A stride parameter
which is allowed to be larger than the number of bytes acutally required
per line MUST be included or the value of this functionality dwindles. This
is true even with the vector based signatures.

The image_surface constructor taking a generator function doesn't need the
closure parameter handling now that we have lambdas (and functors).

The image_surface constructor from a filename indicates that there might be
an underlying image format reader system, which is not described. This
seems not to be feasible at this time. Or it again implicitly refers to png
files.

A color class seems called for. Such an abstraction is present in most all
drawing libraries, except apparently, Cairo. Again this is one of those
classes that are best placed directly in std, to be able to reuse them in
future extensions working with colors in other ways.

The unification of different types of brushes into pattern class hierarchy
seems promising. This should be unified with images, as all of them are
ways of presenting pixel values (color data) at regular 2d positions, i.e.
a raster. The raster_pattern type comes close to the image_memory I
discussed above. Let's at least not have more than one type representing a
in-memory stored x,y indexed raster of pixels!

In the 3D world rasters are regularly called textures. This is today not
really a good name for the actual data even in this application as texture
classes are also used for other things such as for instance bump maps. This
actually goes beyond image data as such, but becomes a matrix type class if
generalized far enough.

To get around this mess it seems logical to follow the path that C++ has
taken in so many other areas, i.e. to templatize the methods and treat the
parameter type (now a T) like a concept. Thus it is the concept of an
"image" or "raster" that would be sdtandardized and then anything that
complies to this concept can be drawn on or blitted onto something else.
However, due to the plethora of storage formats for pixel data and the
large sizes of images an efficient implementation of this is not easy to
implement. I worked in a project which had implemented this and it was the
module that had by far the longest compile times due to the large amount of
template instantiations created. Note also that due to the dynamic nature
of image file loading there must be ways to dispatch to these template
functions at run time depending on the user's selection of file.

The raster_source_pattern has a lot of callbacks and void* closure data
that needs to be cleared out.

I'm not particularly fond of the name 'context' in this case, as it is
rather non-descriptive.

It is not so logical that the actual drawing methods are located in the
context, which mainly is a container for stateful drawing parameters. While
it is established practice (stemming I think from WIN32) to use a notion of
drawing context, I don't even think it really is sound object oriented
design. I would much prefer that the actual drawing commands were methods
on surface, and that these existed both in overloads with a context and
without one (instead taking relevant parameters such as color and dash
pattern for line drawing and brush for filling operations). This sort of
unites the ideas of stateful parameter storage and GDI+ style possibilities
of giving all parameters to each command. Both styles are useful! One
reason for having a drawing context object may be if it enhances thread
safety (i.e. contexts are not thread safe per se byt serialize their
(hidden) interactions with the underlying surface so that several worker
threads can be given parts of the same surface to draw on without
problems). I don't however think that this is the intention of this
proposal, is it?

I would like to see a simple way of rendering an image onto the surface
without the convoluted procedure of first creating a pattern around the
image, then setting this as the "sourc _pattern" of a context and then
drawing a filled rectangle(!) to actually get the image data drawn.

Text output from unicode strings must be as simple as for 8 bit strings.
Proper codepage handling must also be included for the 8 bit case I presume.

Drawing commands need to exist in overloads with int coordinates. This is
the most common source of availability of data for drawing I think.

Drawing commands should primarily work on Point data rather than discrete
coordinate values, although overloads are a possibility. Mainly to reduce
typing when calling but also to increase eficiency as the data is known to
be placed together.

Polyline/polygon drawing should be included, using a range-of-pointers
concept.

The paint() versus stroke() methods which I assume mean to fill and/or
outline closed figures subsequently drawn makes the interface even more
stateful than Win32, as you have both a possibility to set pattern and
enable its use. On the other hand, compared to win32 and its followers,
this gets rid of the need to set an "empty" brush to avoid filling figures,
which is an advantage. The double calls to get a patterned figure is
however error prone. Also, as I understand this, there is no shortcut to
set a solid fill colour (you have to give the context a
solid_colour_pattern to achieve the simplest of filled figures). Most other
libraries has a shortcut for this called "setbackgroundcolour" or something
like this.

As filled/stroked figures are so common I would contemplate encoding this
in the method name even. FillRectangle() and StrokeRectangle() is very easy
to understand... You loose some if you want to do both with the same
rectangle, but in honest, how common is that?

The copy_page() and show_page() seem misplaced in a context type of object,
but if drawing commands were on the surface object they would come more
natural.

--

---
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_1650_32491777.1390768716669
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Here are my comments. I understand that implementing these=
 changes would in some cases imply that it can't be implemented on top of C=
airo, but I don't think that could be a primary objective of a standardized=
 API. I'm not knowledgeable in Cairo but in other drawing APIs and to some =
extent the underlying hardware. I think that it is more important to follow=
 modern C++ paradigms is more important than simplicity of implementation. =
If we are not even taking away the void* context handling which is really a=
rcane we can just as well use the original Cairo library, if you ask me. Al=
so I think that this library is modeled too closely on Win32 with its 80tie=
s style and today almost bizarre ideas of how to organize things. This is d=
efinitely not something we want to perpetuate.<div><br></div><div>Here are =
detailed comments based on reading the synopsis. As the paper does not go i=
nto detail I may have misunderstood some things, I apologize for this alrea=
dy here:<br><div><div><br></div><div>The format enum seems a bit limited, a=
s it does not contain for instance 3x12 bit RGB, which will be more and mor=
e used. Would it be possible to do a struct again to get an open ended set =
of formats. This should also contain the</div><div>subpixel_order informati=
on.</div><div><br></div><div>font_slant and font_weight: For instance wxWid=
gets provides more weight values than normal and bold. Some even has a 0-10=
0 percent weight and slant in degrees. But maybe the enums only provide spe=
cific values on such a gradual scale?</div><div><br></div><div>rectangle an=
d rectangle_int should be replaced with a template, instances of which are =
used in the api. This template along with point&lt;T&gt; should be in the t=
op level std namespace and used throughout std when appropriate. Over time =
this will increase interoperability between 3rd party libraries as they sta=
rt using them.</div><div><br></div><div>Similarly matrix should be called s=
omething like transform_matrix and inherit a generic std::matrix&lt;2,3&gt;=
, adding the affine transform specific setup methods as indicated.</div><di=
v><br></div><div>If the to me a little bizzare class recangle_list exists r=
egion should have a ctor from it.</div><div><br></div><div>Is user_data_key=
 and its use in device/surface really necessary to have?</div><div><br></di=
v><div>Is shared_ptr semantics logical on device, really? It seems to me th=
at these are more in the vein of singletons (although there may be more tha=
n one). That is, you get a handle to it from somewhere central, which you t=
hen never actually copy.</div><div><br></div><div>The same goes for surface=
 unless you can create subsurfaces as rects on a parent surface, in which c=
ase reference counting is appropriate. However, I think that the reference =
counting should only be used between such surface objects, not for all "han=
dles" to any one particular subwindow. This would mean that there would be =
no copy constructors or assignment operators. The ctor taking rect componen=
ts is the one used to create a subsurface (and doing the reference counting=
).</div><div><br></div><div>There should be a ctor of surface which takes a=
 rectangle&lt;double&gt; to describe the subsurface extent, not only one wi=
th four discrete ints. The use of double in this API is strange to me, or n=
eeds to be complemented with a (more commonly used) API using int. The latt=
er solution would be appropriate in the case that using double implies a co=
ordinate transform taking place before the subsurface is created. The hard =
thing about this is that if rotation or shear is included in the transform =
the subwindow can hardly be created.</div><div><br></div><div>get_font_opti=
ons should return a const ref to the internal font_options object. I suspec=
t that this is really a property of the device, but maybe not given recent =
GPU developments.</div><div><br></div><div>It seems that the fallback resol=
ution handling would be more appropriately placed in device.</div><div><br>=
</div><div>mark_dirty_rectange shoud be available with a rectangle&lt;int&g=
t; as parameter. It seems inconsistent that the subsurface creation ctor ta=
kes a double rect and the dirty function takes a int rect.</div><div><br></=
div><div>Is dirty rect handling really a function in this API at all? It is=
 tightly connected to the windowing system event handling, while nothing el=
se in this API really is.</div><div><br></div><div>write_to_png seems as a =
strange function here, as it sets one file format out in front of all other=
s. Of course a image file read/write manager could be added to "make file f=
ormats equal" but I would put this in the hands of 3rd party developers and=
 instead concentrate on standardizing an in-memory image memory class (plac=
ed in std or possibly its own sub-namespace, but not in std::drawing at lea=
st).</div><div><br></div><div>The class image_surface seems to try to "be" =
this image memory, but only for the limited application of drawing in it. T=
his is really a pity as we have lots of other application areas where image=
 memories are important entities.</div><div><br></div><div>vector&lt;char&g=
t; is a very unsuitable way to specify image data as it can't be constructe=
d without being inited to 0. There seems be great opposition against allowi=
ng vectors to default-construct their elements, I have argued for this many=
 a time without any success. In the absense of a real image memory class a =
char* + count API is actually much more appropriate as this allowd image me=
mories from other libraries to be used. A stride parameter which is allowed=
 to be larger than the number of bytes acutally required per line MUST be i=
ncluded or the value of this functionality dwindles. This is true even with=
 the vector based signatures.</div><div><br></div><div>The image_surface co=
nstructor taking a generator function doesn't need the closure parameter ha=
ndling now that we have lambdas (and functors).</div><div><br></div><div>Th=
e image_surface constructor from a filename indicates that there might be a=
n underlying image format reader system, which is not described. This seems=
 not to be feasible at this time. Or it again implicitly refers to png file=
s.</div><div><br></div><div>A color class seems called for. Such an abstrac=
tion is present in most all drawing libraries, except apparently, Cairo. Ag=
ain this is one of those classes that are best placed directly in std, to b=
e able to reuse them in future extensions working with colors in other ways=
..</div><div><br></div><div>The unification of different types of brushes in=
to pattern class hierarchy seems promising. This should be unified with ima=
ges, as all of them are ways of presenting pixel values (color data) at reg=
ular 2d positions, i.e. a raster. The raster_pattern type comes close to th=
e image_memory I discussed above. Let's at least not have more than one typ=
e representing a in-memory stored x,y indexed raster of pixels!</div><div><=
br></div><div>In the 3D world rasters are regularly called textures. This i=
s today not really a good name for the actual data even in this application=
 as texture classes are also used for other things such as for instance bum=
p maps. This actually goes beyond image data as such, but becomes a matrix =
type class if generalized far enough.</div><div><br></div><div>To get aroun=
d this mess it seems logical to follow the path that C++ has taken in so ma=
ny other areas, i.e. to templatize the methods and treat the parameter type=
 (now a T) like a concept. Thus it is the concept of an "image" or "raster"=
 that would be sdtandardized and then anything that complies to this concep=
t can be drawn on or blitted onto something else. However, due to the pleth=
ora of storage formats for pixel data and the large sizes of images an effi=
cient implementation of this is not easy to implement. I worked in a projec=
t which had implemented this and it was the module that had by far the long=
est compile times due to the large amount of template instantiations create=
d. Note also that due to the dynamic nature of image file loading there mus=
t be ways to dispatch to these template functions at run time depending on =
the user's selection of file.</div><div><br></div><div>The raster_source_pa=
ttern has a lot of callbacks and void* closure data that needs to be cleare=
d out.</div><div><br></div><div>I'm not particularly fond of the name 'cont=
ext' in this case, as it is rather non-descriptive.</div><div><br></div><di=
v>It is not so logical that the actual drawing methods are located in the c=
ontext, which mainly is a container for stateful drawing parameters. While =
it is established practice (stemming I think from WIN32) to use a notion of=
 drawing context, I don't even think it really&nbsp;<span style=3D"font-siz=
e: 13px;">is</span><span style=3D"font-size: 13px;">&nbsp;sound object orie=
nted design. I would much prefer that the actual drawing commands were meth=
ods on surface, and that these existed both in overloads with a context and=
 without one (instead taking relevant parameters such as color and dash pat=
tern for line drawing and brush for filling operations). This sort of unite=
s the ideas of stateful parameter storage and GDI+ style possibilities of g=
iving all parameters to each command. Both styles are useful! One reason fo=
r having a drawing context object may be if it enhances thread safety (i.e.=
 contexts are not thread safe per se byt serialize their (hidden) interacti=
ons with the underlying surface so that several worker threads can be given=
 parts of the same surface to draw on without problems). I don't however th=
ink that this is the intention of this proposal, is it?</span></div><div><b=
r></div><div>I would like to see a simple way of rendering an image onto th=
e surface without the convoluted procedure of first creating a pattern arou=
nd the image, then setting this as the "sourc _pattern" of a context and th=
en drawing a filled rectangle(!) to actually get the image data drawn.</div=
><div><br></div><div>Text output from unicode strings must be as simple as =
for 8 bit strings. Proper codepage handling must also be included for the 8=
 bit case I presume.</div><div><br></div><div>Drawing commands need to exis=
t in overloads with int coordinates. This is the most common source of avai=
lability of data for drawing I think.</div><div><br></div><div>Drawing comm=
ands should primarily work on Point data rather than discrete coordinate va=
lues, although overloads are a possibility. Mainly to reduce typing when ca=
lling but also to increase eficiency as the data is known to be placed toge=
ther.</div><div><br></div><div>Polyline/polygon drawing should be included,=
 using a range-of-pointers concept.</div></div></div><div><br></div><div>Th=
e paint() versus stroke() methods which I assume mean to fill and/or outlin=
e closed figures subsequently drawn makes the interface even more stateful =
than Win32, as you have both a possibility to set pattern and enable its us=
e. On the other hand, compared to win32 and its followers, this gets rid of=
 the need to set an "empty" brush to avoid filling figures, which is an adv=
antage. The double calls to get a patterned figure is however error prone. =
Also, as I understand this, there is no shortcut to set a solid fill colour=
 (you have to give the context a solid_colour_pattern to achieve the simple=
st of filled figures). Most other libraries has a shortcut for this called =
"setbackgroundcolour" or something like this.</div><div><br></div><div>As f=
illed/stroked figures are so common I would contemplate encoding this in th=
e method name even. FillRectangle() and StrokeRectangle() is very easy to u=
nderstand... You loose some if you want to do both with the same rectangle,=
 but in honest, how common is that?</div><div><br></div><div>The copy_page(=
) and show_page() seem misplaced in a context type of object, but if drawin=
g commands were on the surface object they would come more natural.</div><d=
iv><br></div></div>

<p></p>

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

------=_Part_1650_32491777.1390768716669--

.

Il giorno 26/gen/2014, alle ore 21:38, Bengt Gustafsson <bengt.gustafsson@b=
eamways.com> ha scritto:

> Here are my comments. <cut>

Hello everybody.

I=92m new to this list and I acknowledge that my opinion might not have a b=
ig weight if at all, but I have my two cents.

I completely agree with Bengt regarding everything he said, but my point go=
es further. With modern C++
gaining relevance thanks to new language features and new common practices,=
 why on earth should the committee
standardize an interface based on an old C library? I think that the idea o=
f basing a standard rendering library
on Cairo (or GDI, or any library designed before C++11 or even before C++98=
) is flawed by principle.

Differently from other standard library facilities or subsystems, a 2D draw=
ing API cannot be designed by
one or few men alone. To get it right, it needs enough field-testing, to be=
 sure that:
1) the API is easy to use (in my opinion, the Qt drawing API is a reference=
 point from this point of view),
2) it is flexible enough, given possible future uses and future hardware ca=
pabilities
3) it doesn=92t impose artificial constraints, allowing the most efficient =
implementation across varying architectures and OSes.

Because of this, proposing an interface (even if a modern, well thought int=
erface), without actually having implemented it and
made it used by actual users for enough time, is a bad idea.

Anyway, should I have to answer my list of bullets, here it is:
1) Please make simple things simple, hard things possible.
  i.e. We all want the highest flexibility, but I don=92t want to create or=
 retrieve 8 objects to draw a filled circle.
2) Please handle fonts in a modern way and flexible. A 2D drawing API is us=
eless nowadays without strong typographic support.
3) This points out the convenience of a text-layout facility.
4) An extensible reading/writing facility for image formats is a must, not =
an option
5) Don=92t ignore platform differences. Giving access to native handles is =
not sufficient. Make it possible to have, for example,
a raster engine, an OpenGL engine, a D3D engine, etc=85=20
6) For the software engine, writing the spec to have (or make it easy to ha=
ve) pixel-to-pixel portability across implementations is a must.
7) Printing support is highly coupled with drawing, and it=92s difficult to=
 get the API right. You need a complete interface to set
   all the possible printing options out there, but with a connection with =
the underlying platform because in GUI code you want to make the
   user choose them with the native interface (this means importing the set=
tings from the native type that represent them, not to handle the=20
8) Interoperability with the underlying platform is essential (again with a=
 standard way to convert types that represents images, brushes,=20
    colors, fonts etc=85 from the native type to the std:: ones).
9) Please give us powerful mathematical and geometrical primitives (a well =
designed and efficient std::matrix and two point<T> and
    rectangle<T> classes are not enough at all)
10) With regards of the previous two points, it would be even better if eve=
rything is abstracted with a trait system like the boost geometric l
     library (but possibly less complex)
11) shared_ptr is good, but why do the API have to expose the memory manage=
d object at all? Let=92s face the users with RAII types that=20
    opaquely handles everything.
12) Please investigate on an FP-like approach to compose drawing operations=
..
  i.e. we have stroke() and fill(), make me compose them to stroke and fill=
 and reuse the composition, in a way that it run faster than execute  two o=
perations again.

Note that I=92m not saying =93Cairo doesn=92t do any of these=94, but even =
if the library itself have strong support for a lot of those points,
the interface is still fundamentally old...

Well I think I=92ve written enough already..=20

Good evening to everyone.

Nicola



--=20

---=20
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-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-proposa=
ls/.

.

On 2014-01-26 15:38, Bengt Gustafsson wrote:
> vector<char> is a very unsuitable way to specify image data as it can't b=
e
> constructed without being inited to 0. There seems be great opposition
> against allowing vectors to default-construct their elements, I have argu=
ed
> for this many a time without any success. In the absense of a real image
> memory class a char* + count API is actually much more appropriate as thi=
s
> allowd image memories from other libraries to be used. A stride parameter
> which is allowed to be larger than the number of bytes acutally required
> per line MUST be included or the value of this functionality dwindles. Th=
is
> is true even with the vector based signatures.

As a generic image class, I would encourage you to look at=20
vil_image_view=C2=B9 from VXL=C2=B2 for possible inspiration. In particular=
, the=20
use of three stride parameters to allow for arbitrary component=20
ordering, including plane-packed and RGB/BGR (though it may be better to=20
separately specify the component ordering in order to allow both ARGB=20
and RGBA). Whether or not your drawing library is able to cope with such=20
arbitrary ordering without conversion, the image class itself becomes=20
more useful if it can be used as a transport for arbitrary packing=20
orders, as this can reduce the need to perform expensive repacking of=20
the pixel data.

I've also found it very useful to be able to construct an image from=20
both a memory address and a std::function that will free the memory, in=20
order to allow copy-free construction from some other image format. For=20
example:

vil_image_view* img =3D obtain_image();
return std::image(..., std::bind(my_vil_free, img));


(=C2=B9=20
http://public.kitware.com/vxl/doc/release/core/vil/html/classvil__image__vi=
ew.html)
(=C2=B2 http://vxl.sourceforge.net/)


> Drawing commands should primarily work on Point data rather than discrete
> coordinate values, although overloads are a possibility. Mainly to reduce
> typing when calling but also to increase eficiency as the data is known t=
o
> be placed together.

These days, is there any strong reason why we would not require users to=20
write:

draw({x, y}, ...); // note the {}'s to implicitly construct a std::point

?

It's only two more characters (to always take coordinates as a=20
std::point or whatever) versus taking coordinates as individual=20
parameters. That's not much cost to avoid having additional overloads of=20
practically every drawing function.


FWIW, I'd like to second Nicola's comment as far as at least considering=20
Qt as a reference API for this design.

--=20
Matthew

--=20

---=20
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-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-proposa=
ls/.

.

On 2014-01-26 18:23, Nicola Gigante wrote:
> 9) Please give us powerful mathematical and geometrical primitives (a well designed and efficient std::matrix and two point<T> and
>      rectangle<T> classes are not enough at all)

If that's truly needed in the standard library, I would suggest looking
at Eigen as a possible reference implementation.

--
Matthew

--

---
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/.

.

I don't know why we would want a object oriented drawing library. I
think it should be completely value-based and algorithms should be
templatized.

On Wed, Jan 22, 2014 at 1:01 AM,  <germandiago@gmail.com> wrote:
> Hello everyone.
>
> I have been taking a look at http://isocpp.org/files/papers/N3888.pdf
>
> Cairo is an object oriented API. No c++ standard library component except
> iostreams is object-oriented.
>
> The current proposal proposes this:
>
>     auto x1 = some_object();
>
>     //Silently aliases x1
>     auto x2 = x1;
>
>
> I think this approach won't be satisfactory, since it violates the usual
> semantics for c++ objects, at least in the standard library.
>
> I see that random_access_iterators vs bidirectional operators provide
> operator +=.
>
> Random_access_iterator -> operator+=
> Bidirectional_iterator       -> std::advance  --- Named function since it is
> expensive.
>
> I have more proposals on how to handle values for the library.
>
> 1. Disable copy with copy constructor, since it's expensive,
> Provide:
>     copy() method for deep copy.
>
> class Texture {
> public:
>     Texture & operator=(Texture const &) = delete;
>     Texture(Texture const &) = delete;
>
>     //Movable
>
>     Texture copy() const;
> private:
>    native_object obj;
> };
>
> Advantages:
>
> - Well known semantics.
> - No need for synchronization. When wanting a reference, you use a true
> reference to the object or
> a pointer, so you know you are aliasing.
> - Avoids copy accidents.
>
> Disadvantage:
>
> - Not reference counted anymore means taking care of lifetime by yourself.
>
>
> 2. Disable copy with copy constructor, since it's expensive.
> Provide:
>     1.- copy() method for deep copy.
>     2.- share() method for sharing the native object.
>
> class Texture {
> public:
>     Texture & operator=(Texture const &) = delete;
>     Texture(Texture const &) = delete;
>
>     //Movable
>
>     Texture copy() const;
>     Texture share() const;
> private:
>     //Reference-counted object
>     shared_ptr<native_object> obj;
> };
>
> Advantages:
>
> - Well known semantics.
>
> Disadvantage:
>
> - You can still alias objects, though aliasing is more explicit since you
> need a call to share().
>
> 3.- Differentiate between mutable and const objects? (Just idea, didn't
> think too much about this yet)
>
> In this case Const objects CANNOT point to mutable objects:
>
> //Mutable
> class Texture {
> public:
>   //Movable but NOT copyable.
>
>   Texture copy() const;
>   ConstTexture const_copy() const;
>
>    //No share() method, make a const_copy first.
> private:
>   native_object obj;
> };
>
>
> //Immutable guaranteed
> class ConstTexture {
>  //Movable and copyable
>
>    Texture muable_copy() const;
> private:
>   shared_ptr<native_object> obj;
> };
>
> 1.- Const objects are freely copyable.
> 2.- Non-const objects must be explicitely copied.
>
> Here my 2 cents. :D
> I think we shouldn't allow implicit sharing, at least, since this is bad for
> multithreaded code in general.
>
>
> --
>
> ---
> 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/.



--
Felipe Magno de Almeida

--

---
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/.

.

On segunda-feira, 27 de janeiro de 2014 15:19:16, Felipe Magno de Almeida
wrote:
> I don't know why we would want a object oriented drawing library. I
> think it should be completely value-based and algorithms should be
> templatized.

You most definitely do not want to run the image-based algorithms like alpha
blending or the Porter-Duff composition modes in inline template code. You want
highly optimised, vector versions of them using the resources of the CPU and
GPU, and not inline.

You could call it a quality-of-implementation issue and allow the
implementation to use extern templates for the known and common image formats.
But I suggest that we *first* get the algorithms for what really matters
settled down, then we figure out how or if they should be made generic.

--
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-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/.

.

On Mon, Jan 27, 2014 at 3:34 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On segunda-feira, 27 de janeiro de 2014 15:19:16, Felipe Magno de Almeida
> wrote:
>> I don't know why we would want a object oriented drawing library. I
>> think it should be completely value-based and algorithms should be
>> templatized.
>
> You most definitely do not want to run the image-based algorithms like alpha
> blending or the Porter-Duff composition modes in inline template code. You want
> highly optimised, vector versions of them using the resources of the CPU and
> GPU, and not inline.

This is easily doable in a templated library with specialization or
SFINAE (or better yet, concepts if already available). Can't see the
problem with
giving a generic programming API and I don't see how OO would help here.

> You could call it a quality-of-implementation issue and allow the
> implementation to use extern templates for the known and common image formats.
> But I suggest that we *first* get the algorithms for what really matters
> settled down, then we figure out how or if they should be made generic.

Isn't it what Cairo has already done? What C++ needs is a generic
drawing library, not another wrapper over cairo. IMO.

> --
> 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


Regards,
--
Felipe Magno de Almeida

--

---
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/.

.

On segunda-feira, 27 de janeiro de 2014 15:45:25, Felipe Magno de Almeida
wrote:
> > You could call it a quality-of-implementation issue and allow the
> > implementation to use extern templates for the known and common image
> > formats. But I suggest that we *first* get the algorithms for what really
> > matters settled down, then we figure out how or if they should be made
> > generic.
> Isn't it what Cairo has already done? What C++ needs is a generic
> drawing library, not another wrapper over cairo. IMO.

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.

Just look at the bikeshed discussions in the SG7 mailing list over what type
we should use for "pixel" and "point".

--
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-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/.

.

On Mon, Jan 27, 2014 at 5:09 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On segunda-feira, 27 de janeiro de 2014 15:45:25, Felipe Magno de Almeida
> wrote:
>> > You could call it a quality-of-implementation issue and allow the
>> > implementation to use extern templates for the known and common image
>> > formats. But I suggest that we *first* get the algorithms for what really
>> > matters settled down, then we figure out how or if they should be made
>> > generic.
>> Isn't it what Cairo has already done? What C++ needs is a generic
>> drawing library, not another wrapper over cairo. IMO.
>
> 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.

> Just look at the bikeshed discussions in the SG7 mailing list over what type
> we should use for "pixel" and "point".
>
> --
> 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


Regards,
--
Felipe Magno de Almeida

--

---
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/.

.

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-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/.

.

--001a1134bb9a7f168104f0fcbb13
Content-Type: text/plain; charset=UTF-8

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 <thiago@macieira.org>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-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/.
>

--

---
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/.

--001a1134bb9a7f168104f0fcbb13
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;m in the process of providing more detailed ans=
wers because the I appreciate the earlier feedback=C2=A0and feel that it is=
=C2=A0helpful.=C2=A0As such=C2=A0I think=C2=A0each=C2=A0post=C2=A0deserve a=
 detailed response.</div><div>=C2=A0</div>
<div>But I just wanted to pause to say that I think that=C2=A0Thiago&#39;s =
post is a=C2=A0excellent summary of things as they stand going in to Issaqu=
ah.</div><div>=C2=A0</div><div>Elsewhere, in a humorous context, I summariz=
ed it as follows:=C2=A0If N3888 were incorporated into the=C2=A0Standard as=
-is, I would feel compelled to request that the Issaquah Police Department =
investigate the possibility that we had all been unknowingly exposed to som=
e substance with psychotropic properties. :)</div>
<div>=C2=A0</div><div>-Mike</div><div>=C2=A0</div><div><br></div><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Jan 27, 2014 at 7:01 PM=
, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.o=
rg" target=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">On segunda-feira, 27 de janeiro de 2014 18:06:49, Felipe M=
agno de Almeida<br>

wrote:<br>
<div class=3D"im">&gt; &gt; I&#39;m arguing that we need an efficient C++ l=
ibrary more than we need a<br>
&gt; &gt; generic one. So I&#39;m arguing to *first* get what matters, and =
then<br>
&gt; &gt; generalise.<br>
&gt; If what you mean by first is that it is included to the C++ standard<b=
r>
&gt; library, then<br>
&gt; I would be against. Not that I can vote :). If you meant someone writi=
ng a<br>
&gt; new C++ library, then I&#39;m always for it. The more the merrier, of =
course.<br>
<br>
</div>That&#39;s partially what I meant. In my opinion, having a library th=
at cannot<br>
possibly do ARGB32 efficiently is a disservice to C++ developers, even if i=
t can<br>
also do ARGB48, ARGB64, RGB565, YUV420, HSV, and other crazy pixel formats.=
<br>
<br>
I meant that we first need to figure out the API, we need to get started<br=
>
somewhere. Let&#39;s figure out what we need, how it would work, and how it=
 can be<br>
implemented efficiently. Without a reference implementation that passes bas=
ic<br>
quality check, we&#39;ll get nowhere. This is why the current proposal is b=
ased on<br>
Cairo: it implements today&#39;s technology efficiently, even if the API is=
 not very<br>
C++-like yet.<br>
<br>
After we get that, we can study generalisations without compromising the<br=
>
quality. Once that is done, it can be proposed to the standard.<br>
<br>
We&#39;re still trying to get step 1 done.<br>
<div class=3D"im HOEnZb">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4 535=
8<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--001a1134bb9a7f168104f0fcbb13--

.

------=_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<std::string, float>, 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 <random> 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 <thi...@macieira.org<javascript:>
> > 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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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

<div dir=3D"ltr">I think this is a great thing and thank you for doing this=
.. Having a standard 2D graphics library would be great.<br><br>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&lt;&lt;, 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&lt;std::string=
, float&gt;, 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)<br><br>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&gt; as opposed to those used in iostreams)<br><br>Cheers,<br><br>M=
alte<br><br>On Monday, January 27, 2014 7:16:14 PM UTC-5, Michael McLaughli=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
I'm in the process of providing more detailed answers because the I appreci=
ate the earlier feedback&nbsp;and feel that it is&nbsp;helpful.&nbsp;As suc=
h&nbsp;I think&nbsp;each&nbsp;post&nbsp;deserve a detailed response.</div><=
div>&nbsp;</div>
<div>But I just wanted to pause to say that I think that&nbsp;Thiago's post=
 is a&nbsp;excellent summary of things as they stand going in to Issaquah.<=
/div><div>&nbsp;</div><div>Elsewhere, in a humorous context, I summarized i=
t as follows:&nbsp;If N3888 were incorporated into the&nbsp;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. :)</div>
<div>&nbsp;</div><div>-Mike</div><div>&nbsp;</div><div><br></div><div><div =
class=3D"gmail_quote">On Mon, Jan 27, 2014 at 7:01 PM, Thiago Macieira <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"nuWF5-LlVsEJ" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">thi...@macieira.org<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">On segunda-feira, 27 de janeiro de 2014 18:06:49, Felipe M=
agno de Almeida<br>

wrote:<br>
<div>&gt; &gt; I'm arguing that we need an efficient C++ library more than =
we need a<br>
&gt; &gt; generic one. So I'm arguing to *first* get what matters, and then=
<br>
&gt; &gt; generalise.<br>
&gt; If what you mean by first is that it is included to the C++ standard<b=
r>
&gt; library, then<br>
&gt; I would be against. Not that I can vote :). If you meant someone writi=
ng a<br>
&gt; new C++ library, then I'm always for it. The more the merrier, of cour=
se.<br>
<br>
</div>That's partially what I meant. In my opinion, having a library that c=
annot<br>
possibly do ARGB32 efficiently is a disservice to C++ developers, even if i=
t can<br>
also do ARGB48, ARGB64, RGB565, YUV420, HSV, and other crazy pixel formats.=
<br>
<br>
I meant that we first need to figure out the API, we need to get started<br=
>
somewhere. Let's figure out what we need, how it would work, and how it can=
 be<br>
implemented efficiently. Without a reference implementation that passes bas=
ic<br>
quality check, we'll get nowhere. This is why the current proposal is based=
 on<br>
Cairo: it implements today's technology efficiently, even if the API is not=
 very<br>
C++-like yet.<br>
<br>
After we get that, we can study generalisations without compromising the<br=
>
quality. Once that is done, it can be proposed to the standard.<br>
<br>
We're still trying to get step 1 done.<br>
<div>--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%=
2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62F=
W8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75h=
ttp%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7=
euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=3D"ht=
tp://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.goog=
le.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJ=
do5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http://www.=
google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCN=
HGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a><br>
&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center<br>
&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:<br>
&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4 535=
8<br>
<br>
</div><div><div>--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
nuWF5-LlVsEJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"nuWF5-LlVsEJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div>

<p></p>

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

------=_Part_4170_19733406.1390881006608--

.

--nextPart1786346.OJt2Vyyhh9
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On segunda-feira, 27 de janeiro de 2014 19:50:06, malteskarupke@gmail.com
wrote:
> I don't think that a standard 2D graphics library has to be the most
> efficient graphics library around.

I don't think it has to be. But it has to have reasonable performance for
regular things like ARGB32 and opaque composition modes.
--
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

--nextPart1786346.OJt2Vyyhh9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBS5znrM/XwBW70U1gRAjZVAJwK8FKRikN3XLCRoD8Q3U3fYxOOEACfWAwf
pf0Sw8dQvZo2FVYeWV+n7mY=
=bp55
-----END PGP SIGNATURE-----

--nextPart1786346.OJt2Vyyhh9--


.

--047d7b5d3b6e5b9e1304f1020632
Content-Type: text/plain; charset=UTF-8

>
> Here are my comments. I understand that implementing these changes would
> in some cases imply that it can't be implemented on top of Cairo, but I
> don't think that could be a primary objective of a standardized API. I'm
> not knowledgeable in Cairo but in other drawing APIs and to some extent the
> underlying hardware. I think that it is more important to follow modern C++
> paradigms is more important than simplicity of implementation. If we are
> not even taking away the void* context handling which is really arcane we
> can just as well use the original Cairo library, if you ask me. Also I
> think that this library is modeled too closely on Win32 with its 80ties
> style and today almost bizarre ideas of how to organize things. This is
> definitely not something we want to perpetuate.
>
>
First, thank you for the detailed, insightful feedback! I appreciate it
very much.

Interestingly enough, while cairo does bear some resemblance to the
Win32/GDI drawing model, its origins are in X11. The library was originally
named Xr and was meant to be a significant improvement over raw Xlib
programming. I believe that the name changed when the library was changed
to be cross-platform (with English pronunciations of the Greek letter
names (Chi Rho) used as basis the current name).

I very much agree that we want a clean, modern C++ library at the end of
the day. N3888 is offered as a possible starting point for reaching that
goal. In hindsight I should've made that much clearer in the paper. The
hope for N3888 is that it, or a revision to it, will be accepted by the SG
as a starting point, with amendments and modifications made to move it away
from the C-like style that it still retains to a clean, modern design that
would ultimately become a TS. More on that below as I address your points
individually.


Here are detailed comments based on reading the synopsis. As the paper does
> not go into detail I may have misunderstood some things, I apologize for
> this already here:
>
> The format enum seems a bit limited, as it does not contain for instance
> 3x12 bit RGB, which will be more and more used. Would it be possible to do
> a struct again to get an open ended set of formats. This should also
> contain the
> subpixel_order information.
>
>
Right now the semantics of the library are as defined in the cairo API
documentation: http://cairographics.org/manual/ . The subpixel order
details are described there and are defined in a way that they are reliant
on the machine endianness.

We've decided to handle proposed changes by making them issues tagged with
"enhancement" in the GitHub repository for the reference implementation:
https://github.com/mikebmcl/N3888_RefImpl/issues?state=open . I had already
added an issue suggesting that subpixel order be changed to adopt a
specific byte order, regardless of endianness, for places where the user
can retrieve or supply a vector of image data as unsigned chars. I'm not
sure how we should handle it if we ever add a function to give the user a
raw pointer to the data itself; in that case I suspect that we would just
have to trust that the user knows what he or she is doing.

I've added the suggestions to switch format to a struct with subpixel order
info included and to add additional formats as issues to the GitHub repo.
For the format struct, a brief code snippet showing how you see it working
would be helpful to me (and maybe others) in thinking about it. If you find
a moment to do that, please feel free to add it directly to the issue:
https://github.com/mikebmcl/N3888_RefImpl/issues/12 . If you prefer just to
post it here instead then I will take care of adding it there.

I generally agree about adding more formats. I added some thoughts I have
on practical implications we'll need to resolve if we do that to the GitHub
issue for that. (The gist of them being that since not all GPUs support all
formats, we'll need to decide how to handle unsupported formats, and that
it'd also be good to consider what, if any, mandatory formats there should
be).

Rather than me saying it each time, you can assume that I added an issue
for each point I responded to unless I explicitly say that I didn't for
some reason.



>  font_slant and font_weight: For instance wxWidgets provides more weight
> values than normal and bold. Some even has a 0-100 percent weight and slant
> in degrees. But maybe the enums only provide specific values on such a
> gradual scale?
>

I'm strongly in favor of keeping the API (especially the text parts) simple
for now. I think font_slant should stay as is. I'm open to adding more
weights but not many and I think that should be deferred until later in the
process of getting to a TS. Later in the design process, we might
also consider adding a UDL to provide finer-grained control over the weight
on systems that support it. But I need to think about that more before I'd
be able to vote for or against it. As much as is reasonable, I want to
avoid appearing to offer options that in reality would only really work on
some platforms.

I think that in general we can go a bit above the least common denominator
(especially where there's a reasonable fallback for platforms that don't
support a particular feature). But I'd rather be in the position of
receiving requests for more features than complaints that implementations
aren't delivering what the interface appears, at a casual glance, to offer.

My view here is to defer consideration of this until later in the process.



> rectangle and rectangle_int should be replaced with a template, instances
> of which are used in the api. This template along with point<T> should be
> in the top level std namespace and used throughout std when appropriate.
> Over time this will increase interoperability between 3rd party libraries
> as they start using them.
>
>
I definitely agree as far as creating a point type. I need to think more
about the merits of templating point and rectangle; it seems obviously good
but I'm unsure if it might not haunt us someday (not doing it might also
haunt us; this is something I hope more people comment on either here or in
Issaquah). I'm not sure about trying to hoist such types into std right
now. I think any decision to move these types out of drawing would be the
purview of LWG/LEWG.

So I'm adding a suggestion to create these class template types but I'm not
adding in a suggestion to move them to std. That'd require a separate
proposal. I would expect it to have a detailed analysis of why they should
be added to std, what effects adding them directly to std can and should
have, and how and whether those types should interact with other Standard
Library functionality (at a minimum). I also think it should be presented
directly to LEWG, absent some instruction from them to re-route it
elsewhere. If someone writes such a proposal and it is adopted, then we can
always adopt those types in this library so long as the TS hasn't yet been
published (even if it has, we could still probably work something out,
though it'd be harder).


Similarly matrix should be called something like transform_matrix and
> inherit a generic std::matrix<2,3>, adding the affine transform specific
> setup methods as indicated.
>

I think this is a good idea, but I'm not adding it as a suggestion because
I think the creation a matrix type falls under SG6 and so should be
presented via a proposal to them (assuming they aren't already considering
it). If SG6 is working on or decides to work on a matrix type, we should
coordinate with them to follow its development and make use of it. I did
add in a "question" issue as a reminder to check with SG6 about this. If
they don't take it up, I don't see any reason for us to develop a generic
matrix type when all we need is a 2x3 matrix for affine transformations.

Regardless, until we check with SG6 and hear back from them, I don't think
there's anything for us to discuss just yet. But the matrix type we have
now needs work so if they don't take it up then I think we should consider
changing the name (in case they decide to take it up in the future) and
should clean up the type (including adding appropriate operator overloads,
etc.). Someone else suggested that already and I still need to go back and
add that and other suggestions that were made before the reference
implementation was published in to the issue tracker.

Incidentally, the standard suggests in a footnote that a hypothetical
matrix class could be built up using the valarray class template. We might
want to consider doing that here if we are left to our own devices in terms
of the matrix type.



> If the to me a little bizzare class recangle_list exists region should
> have a ctor from it.
>
>
Added as a suggestion. And I agree that it's a bizarre type. I think it
should probably be replaced with a vector<rectangle> and will be surprised
if it isn't. I added that as a suggestion too.


Is user_data_key and its use in device/surface really necessary to have?
>
>
As far as I'm concerned, user_data_key (and the functionality it exists to
provide) should be obliterated. It's already a suggestion. But it's nice to
know that others also question its usefulness.


Is shared_ptr semantics logical on device, really? It seems to me that
> these are more in the vein of singletons (although there may be more than
> one). That is, you get a handle to it from somewhere central, which you
> then never actually copy.
>
>
I honestly don't know if there's a legitimate reason to have the device
type at all. I added a note to investigate it for possible elimination.
During the discussion of that, if we decide it has a purpose we would
then go on to decide its semantics. It's there because it came along as
part of the mechanical transformation.



> The same goes for surface unless you can create subsurfaces as rects on a
> parent surface, in which case reference counting is appropriate. However, I
> think that the reference counting should only be used between such surface
> objects, not for all "handles" to any one particular subwindow. This would
> mean that there would be no copy constructors or assignment operators. The
> ctor taking rect components is the one used to create a subsurface (and
> doing the reference counting).
>
>
You can create subsurfaces from parent surfaces. Further, you can create an
image_surface, make it the target of contextA, draw on it with contextA,
and then draw it to the target surface of contextB by creating a
surface_pattern from it or by calling contextB::set_source_surface [which
creates an ad hoc surface_pattern and sets it as the source pattern on the
context]. In other words, you can use image_surface objects as render
targets (and this in turn is a key part of the pattern that allows you to
implement multi-threaded graphics without stalling the thread that renders
to your output device). If you'll be in Issaquah, part of the presentation
I'll be giving there is going to cover in depth the reason why I think that
shared ownership semantics are the right way to go for these types. I'll
also share my slides for the benefit of everyone who can't be there. The
rough-draft soundbite version is that shared ownership semantics give you
clean, modern-looking C++ without having everything wrapped in a shared_ptr
(ugly and a non-trivial possibility of misuse, especially by newcomers to
C++) while respecting the fact that deep copies of GPU resources will
decimate performance and increase memory usage without any real benefit to
the end user (even if you wanted a copy of a texture, the best way to
create it is to draw it as a sprite to a render target).

That said, shared ownership semantics are not a final decision. I think
they are justified here and will be making a formal case for it, but the
decision will ultimately rest in the hands of LEWG and SG13. We may well
end up with move-only semantics for GPU objects. I very much doubt we would
decide on value semantics due to the expense of copying GPU resources. I
added an issue for this for the sake of completeness.


There should be a ctor of surface which takes a rectangle<double> to
> describe the subsurface extent, not only one with four discrete ints. The
> use of double in this API is strange to me, or needs to be complemented
> with a (more commonly used) API using int. The latter solution would be
> appropriate in the case that using double implies a coordinate transform
> taking place before the subsurface is created. The hard thing about this is
> that if rotation or shear is included in the transform the subwindow can
> hardly be created.
>
>
Oddly enough, cairo states that the semantics for the function that the
ctor derives from are only defined if you use whole units. Non whole units
have not been finalized as of yet. Given that, I don't see any reason to
keep this as a double (what it is currently). That said, I'm not adding it
as an issue simply because when the issue of what to do about the proposed
point type and the existing rectangle and rectangle_int types is resolved,
what will follow will be rules transforming these sorts of functions into
functions that take the appropriate resulting type. That was one of the
transforms we intended to include (it's noted as a comment at the end of
N3825) but that I did not get around to including in N3888 (in part because
I figured that people would want to discuss how we should define types such
as point, rectangle, etc.). So rather than create types where none existed,
I stuck with cairo's types and transformed them. Since cairo has no point
type, N3888 has no point type. But there will be one and when there is
there will be a new transformation rule added to section 2 of the rules
that will cover it.



> get_font_options should return a const ref to the internal font_options
> object. I suspect that this is really a property of the device, but maybe
> not given recent GPU developments.
>
>
This isn't the only place where this "out" parameter pattern occurs. It
definitely needs to be eliminated wherever possible. I just did not want to
do it on the first pass since the transform rules are already quite complex
and my hope is that by having kept them as simple as possible, people will
spot any bugs or problems with them (as indeed people have; the rules call
for virtual dtors for base classes but it was a late rule and I did not get
around to changing it in the reference implementation until after
publication and so I also forgot to fix it in the Technical Specification
section). But it's in the queue now so that when the time is right it will
be dealt with.


It seems that the fallback resolution handling would be more appropriately
> placed in device.
>
> mark_dirty_rectange shoud be available with a rectangle<int> as parameter.
> It seems inconsistent that the subsurface creation ctor takes a double rect
> and the dirty function takes a int rect.
>
> Is dirty rect handling really a function in this API at all? It is tightly
> connected to the windowing system event handling, while nothing else in
> this API really is.
>
>
The fallback resolution functionality has to do with non-raster output
surfaces (e.g. printers, PDFs, SVGs). I don't know of any good reason to
exclude these as potential surfaces that an implementation could choose to
let a user draw to just now so I see no reason to consider removing that
functionality at this point. As such I'm not adding an issue for it. There
will be later passes through the API to remove functionality that wound up
becoming unused or unnecessary. The only things I'm willing to put up for
removal now are things that are unambiguously unnecessary (e.g. the
user_data_key stuff). The dirty rect handling functionality is how cairo is
informed that something else was drawing to the surface. While we aren't
standardizing cairo, having these function calls available to implementers
could facilitate interop where they choose to provide useful native handles
to enable that. So it may well have uses. If not, we'll eliminate it in a
later pass.


write_to_png seems as a strange function here, as it sets one file format
> out in front of all others. Of course a image file read/write manager could
> be added to "make file formats equal" but I would put this in the hands of
> 3rd party developers and instead concentrate on standardizing an in-memory
> image memory class (placed in std or possibly its own sub-namespace, but
> not in std::drawing at least).
>
> The class image_surface seems to try to "be" this image memory, but only
> for the limited application of drawing in it. This is really a pity as we
> have lots of other application areas where image memories are important
> entities.
>
> vector<char> is a very unsuitable way to specify image data as it can't be
> constructed without being inited to 0. There seems be great opposition
> against allowing vectors to default-construct their elements, I have argued
> for this many a time without any success. In the absense of a real image
> memory class a char* + count API is actually much more appropriate as this
> allowd image memories from other libraries to be used. A stride parameter
> which is allowed to be larger than the number of bytes acutally required
> per line MUST be included or the value of this functionality dwindles. This
> is true even with the vector based signatures.
>

> The image_surface constructor taking a generator function doesn't need the
> closure parameter handling now that we have lambdas (and functors).
>
> The image_surface constructor from a filename indicates that there might
> be an underlying image format reader system, which is not described. This
> seems not to be feasible at this time. Or it again implicitly refers to png
> files.
>

It comes from cairo's PNG functionality. I'm in favor of extending it to
more image types rather than eliminating it.

You can call image_surface::get_data and write it out to whatever format
you want. Or do whatever you want with the resulting data for that matter.

There's already an issue open to allow users direct access to pointers. I
think having both is the best way to go since it leave the choice of safety
versus performance in the hands of the user. Also, you can construct a
vector without zero initializing it provided you have data to put in it
already. The reference implementation does this in image_data::get_data.
And if you don't have data to put in it right away, you can still call
reserve on it. You're restricted in how you insert data when you use
reserve rather than resize, but reserve will not zero initialize the
memory. The library already has functionality that tells you the stride
given a format and line width in pixels.

I added an issue to verify that the void* closure parameters are useless
and then remove them from all of the functions that have them.

Yeah, it's PNG again (the filename ctor). I have an email from the cairo
mailing list to do something about this but haven't had a chance to turn it
into an issue yet. The suggestion there was to make it a static factory
function (likely a member function) which has some appeal for me. I much
prefer adding in support for more image types than removing the
functionality regardless of how it is handled.

>
> A color class seems called for. Such an abstraction is present in most all
> drawing libraries, except apparently, Cairo. Again this is one of those
> classes that are best placed directly in std, to be able to reuse them in
> future extensions working with colors in other ways.
>

Right now I see no reason for one. Further, the class has the potential to
become a nightmare class of doom as soon as it starts to flirt with
concrete representations of colors in pixel formats. If someone wants to
draw up a proposal to add a color class, they can. If it's going to go
directly in std, it should be directed to LEWG initially and only sent to
SG13 if LEWG decides to do so.

Don't get me wrong, I like color classes (even if it's just an aggregate of
const statics. How else am I supposed to know what values to use to get
cornflower blue or any number of other named colors that I'm used to having
available). And it may be that one will prove both useful and feasible
here. But it's non-trivial and it's not something that must exist to
evaluate N3888 as a starting point for a 2D drawing library. So I'm not
adding it as an issue at this time. (Note: I'm not the only person who can
add issues so if someone feels that it absolutely must exist, they can add
it and include a very good reason why it must exist now because otherwise
the chair may decide not to entertain it).



> The unification of different types of brushes into pattern class hierarchy
> seems promising. This should be unified with images, as all of them are
> ways of presenting pixel values (color data) at regular 2d positions, i.e.
> a raster. The raster_pattern type comes close to the image_memory I
> discussed above. Let's at least not have more than one type representing a
> in-memory stored x,y indexed raster of pixels!
>

I'm not going to add an issue that will mess with cairo's basic type system
right now. I think that's something to discuss after there's a starting
point. Even then I would be against it. image_surface serves as a render
target. A pattern does not and cannot. Cairo calls it a pattern, other
libraries use terms like brush. The concept of pattern/brush being distinct
from surface/texture is very much a part of the 2D libraries I'm familiar
with. Just because all data is bytes doesn't mean we should abandon good
conceptual frameworks to in order to generalize concepts.



> In the 3D world rasters are regularly called textures. This is today not
> really a good name for the actual data even in this application as texture
> classes are also used for other things such as for instance bump maps. This
> actually goes beyond image data as such, but becomes a matrix type class if
> generalized far enough.
>
>
The term texture isn't used anywhere in the drawing header. I'm not quite
sure what you're talking about here. Perhaps I'm misunderstanding you?



> To get around this mess it seems logical to follow the path that C++ has
> taken in so many other areas, i.e. to templatize the methods and treat the
> parameter type (now a T) like a concept. Thus it is the concept of an
> "image" or "raster" that would be sdtandardized and then anything that
> complies to this concept can be drawn on or blitted onto something else.
> However, due to the plethora of storage formats for pixel data and the
> large sizes of images an efficient implementation of this is not easy to
> implement. I worked in a project which had implemented this and it was the
> module that had by far the longest compile times due to the large amount of
> template instantiations created. Note also that due to the dynamic nature
> of image file loading there must be ways to dispatch to these template
> functions at run time depending on the user's selection of file.
>
> The raster_source_pattern has a lot of callbacks and void* closure data
> that needs to be cleared out.
>

Yeah, raster_source_pattern is complicated. The closures are wrapped up in
the earlier issue re: closures. Most of the callbacks are used only in some
non-typical cases; only acquire is mandatory. But I'm not yet ready to
throw out the functionality. It does have uses (customizations when dealing
with a printing surface, for example) so I'm not adding it as an issue at
this time. We can remove it later if it still seems unnecessary then.



> I'm not particularly fond of the name 'context' in this case, as it is
> rather non-descriptive.
>
>
Bike shed. Also D3D11, OpenGL, and Quartz 2D use context in the names of
their objects that perform drawing operations to a surface. SDL
and openFrameworks use it as a result of their ties with OpenGL. So I would
not characterize it as non-descriptive. In fact, being a graphics::context
object is the best, non-repetitive name for it in my opinion.



> It is not so logical that the actual drawing methods are located in the
> context, which mainly is a container for stateful drawing parameters. While
> it is established practice (stemming I think from WIN32) to use a notion of
> drawing context, I don't even think it really is sound object oriented
> design. I would much prefer that the actual drawing commands were methods
> on surface, and that these existed both in overloads with a context and
> without one (instead taking relevant parameters such as color and dash
> pattern for line drawing and brush for filling operations). This sort of
> unites the ideas of stateful parameter storage and GDI+ style possibilities
> of giving all parameters to each command. Both styles are useful! One
> reason for having a drawing context object may be if it enhances thread
> safety (i.e. contexts are not thread safe per se byt serialize their
> (hidden) interactions with the underlying surface so that several worker
> threads can be given parts of the same surface to draw on without
> problems). I don't however think that this is the intention of this
> proposal, is it?
>
>
As explained at the beginning of this reply, cairo's origins are in X11 and
Win32 wasn't even contemplated at the time. Regardless, drawing methods on
a context are, as you point out, established practice, and the most recent
major library to adopt this was D3D11 (D3D10 and earlier had drawing
on done by the device itself). The context object is central to the
proposal. I have some issues filed to consider moving some categories of
functionality off of it. But the transform you are asking for requires a
fundamentally new proposal.


I would like to see a simple way of rendering an image onto the surface
> without the convoluted procedure of first creating a pattern around the
> image, then setting this as the "sourc _pattern" of a context and then
> drawing a filled rectangle(!) to actually get the image data drawn.
>
>
Me too. This can easily be added later since it is
already possible now. It's not central to evaluating N3888 as a starting
point so I'm not filing an issue for it.


Text output from unicode strings must be as simple as for 8 bit strings.
> Proper codepage handling must also be included for the 8 bit case I presume.
>
>
The API as it stands deals in UTF-8 only. I'd be willing to entertain
UTF-16 or UTF-32, but codepages must die. I have no interest in diving into
the realm of locales and codepages for a modern library. Unless Bjarne
himself asks for it or my coauthors demand it, it's not going into this
proposal or anything based on it. Sorry.



> Drawing commands need to exist in overloads with int coordinates. This is
> the most common source of availability of data for drawing I think.
>
> Drawing commands should primarily work on Point data rather than discrete
> coordinate values, although overloads are a possibility. Mainly to reduce
> typing when calling but also to increase eficiency as the data is known to
> be placed together.
>
> Polyline/polygon drawing should be included, using a range-of-pointers
> concept.
>
> The paint() versus stroke() methods which I assume mean to fill and/or
> outline closed figures subsequently drawn makes the interface even more
> stateful than Win32, as you have both a possibility to set pattern and
> enable its use. On the other hand, compared to win32 and its followers,
> this gets rid of the need to set an "empty" brush to avoid filling figures,
> which is an advantage. The double calls to get a patterned figure is
> however error prone. Also, as I understand this, there is no shortcut to
> set a solid fill colour (you have to give the context a
> solid_colour_pattern to achieve the simplest of filled figures). Most other
> libraries has a shortcut for this called "setbackgroundcolour" or something
> like this.
>
> As filled/stroked figures are so common I would contemplate encoding this
> in the method name even. FillRectangle() and StrokeRectangle() is very easy
> to understand... You loose some if you want to do both with the same
> rectangle, but in honest, how common is that?
>
> The copy_page() and show_page() seem misplaced in a context type of
> object, but if drawing commands were on the surface object they would come
> more natural.
>
>
copy_page and show_page are related to the functionality that allows
surfaces to be things like printers, PDFs, etc. It stays for now for the
reasons previously described.

The need for some sort of clear function that clears the surface to a
specified color is definitely something to add in the future. This and the
other things aren't things I'm inclined to add to the (ever increasing)
issues list since they can be done later once we've decided on whether
N3888 or N3888 with modifications will be a suitable starting point for the
library.

Thank you again for taking the time to make all these recommendations!

-Mike

--

---
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/.

--047d7b5d3b6e5b9e1304f1020632
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-lef=
t:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-=
style:solid">


<div dir=3D"ltr">Here are my comments. I understand that implementing these=
 changes would in some cases imply that it can&#39;t be implemented on top =
of Cairo, but I don&#39;t think that could be a primary objective of a stan=
dardized API. I&#39;m not knowledgeable in Cairo but in other drawing APIs =
and to some extent the underlying hardware. I think that it is more importa=
nt to follow modern C++ paradigms is more important than simplicity of impl=
ementation. If we are not even taking away the void* context handling which=
 is really arcane we can just as well use the original Cairo library, if yo=
u ask me. Also I think that this library is modeled too closely on Win32 wi=
th its 80ties style and today almost bizarre ideas of how to organize thing=
s. This is definitely not something we want to perpetuate.<div>


<br></div></div></blockquote><div>=C2=A0 </div><div>First, thank you for th=
e detailed, insightful feedback! I appreciate it very much.</div><div>=C2=
=A0</div><div>Interestingly enough, while cairo does bear some resemblance =
to the Win32/GDI drawing model, its origins are in X11. The library was ori=
ginally named Xr and was meant=C2=A0to be=C2=A0a significant improvement ov=
er raw Xlib programming. I believe that the name changed when the library w=
as changed to be cross-platform (with English pronunciations of the Greek l=
etter names=C2=A0(Chi=C2=A0Rho)=C2=A0used as basis=C2=A0the=C2=A0current na=
me).</div>


<div>=C2=A0</div><div>I=C2=A0very much=C2=A0agree that=C2=A0we want a clean=
,=C2=A0modern C++ library at the end of the day. N3888 is offered as a poss=
ible starting point for reaching that goal. In hindsight I should&#39;ve ma=
de that much clearer in the paper. The hope for N3888 is that it, or a revi=
sion to it, will be accepted by the SG as a starting point, with amendments=
 and modifications made to move it away from the C-like style that it still=
 retains to a clean, modern design that would ultimately become a TS. More =
on that below as I address your=C2=A0points individually.</div>


<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div></di=
v><div>


Here are detailed comments based on reading the synopsis. As the paper does=
 not go into detail I may have misunderstood some things, I apologize for t=
his already here:<br><div><div><br></div><div>The format enum seems a bit l=
imited, as it does not contain for instance 3x12 bit RGB, which will be mor=
e and more used. Would it be possible to do a struct again to get an open e=
nded set of formats. This should also contain the</div>


<div>subpixel_order information.</div><div><br></div></div></div></div></bl=
ockquote><div>=C2=A0</div><div>Right now the semantics of the library are a=
s defined in the cairo API documentation:=C2=A0<a href=3D"http://cairograph=
ics.org/manual/" target=3D"_blank">http://cairographics.org/manual/</a> . T=
he subpixel order details=C2=A0are described there and are defined in a way=
 that they are reliant on the machine endianness.</div>


<div>=C2=A0</div><div>We&#39;ve decided to handle proposed changes by makin=
g them issues tagged=C2=A0with &quot;enhancement&quot; in the GitHub reposi=
tory for the reference implementation: <a href=3D"https://github.com/mikebm=
cl/N3888_RefImpl/issues?state=3Dopen" target=3D"_blank">https://github.com/=
mikebmcl/N3888_RefImpl/issues?state=3Dopen</a> . I had=C2=A0already added a=
n issue suggesting that=C2=A0subpixel order=C2=A0be changed to adopt a spec=
ific byte order, regardless of endianness, for places where the user can re=
trieve or supply a vector of image data as unsigned chars. I&#39;m not sure=
=C2=A0how we should handle it=C2=A0if=C2=A0we ever add a function to give t=
he user=C2=A0a raw pointer to the data itself; in that case I suspect that=
=C2=A0we would just have to trust that the user knows what he or she is doi=
ng.</div>


<div>=C2=A0</div><div>I&#39;ve added the suggestions to switch format to a =
struct with subpixel order info included and to add additional formats as i=
ssues to the GitHub repo. For the format struct, a brief code snippet showi=
ng how you see it working would be helpful to me (and maybe others)=C2=A0in=
 thinking about it. If you find a moment to do that, please feel free to ad=
d it directly to the issue: <a href=3D"https://github.com/mikebmcl/N3888_Re=
fImpl/issues/12">https://github.com/mikebmcl/N3888_RefImpl/issues/12</a> . =
If you prefer just=C2=A0to post it here instead then I will take=C2=A0care =
of adding it there.</div>
<div>=C2=A0</div><div>I generally agree about adding more formats.=C2=A0I a=
dded some thoughts I have on practical implications we&#39;ll need to resol=
ve if we do that to the GitHub issue for that. (The gist of them being that=
 since not all GPUs support all formats, we&#39;ll need to decide how to ha=
ndle unsupported formats, and that it&#39;d also be good to consider what, =
if any, mandatory formats there should be).</div>
<div>=C2=A0</div><div>Rather than me saying it each time, you can assume th=
at I added an issue for each point I responded to unless I explicitly say t=
hat I didn&#39;t for some reason.</div><div>=C2=A0</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-l=
eft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-lef=
t-style:solid">
<div dir=3D"ltr">
<div>
<div><div></div><div>font_slant and font_weight: For instance wxWidgets pro=
vides more weight values than normal and bold. Some even has a 0-100 percen=
t weight and slant in degrees. But maybe the enums only provide specific va=
lues on such a gradual scale?</div>
</div></div></div></blockquote><div>=C2=A0</div><div>I&#39;m strongly in fa=
vor=C2=A0of keeping the API=C2=A0(especially the text parts) simple for now=
.. I think font_slant should stay as is. I&#39;m open to adding more weights=
 but not many and I think that should be deferred until later in the proces=
s of getting to a TS. Later in the design process, we=C2=A0might also=C2=A0=
consider adding a UDL to provide finer-grained control over the weight on s=
ystems that support it.=C2=A0But I need to think about that more before I&#=
39;d be able to vote for or against it.=C2=A0As much as=C2=A0is reasonable,=
 I want to avoid=C2=A0appearing to offer options that=C2=A0in reality would=
 only really work on some platforms.</div>
<div>=C2=A0</div><div>I think that in general we can go a bit above the lea=
st common denominator (especially=C2=A0where there&#39;s a reasonable fallb=
ack for platforms that don&#39;t support a particular feature). But I&#39;d=
 rather be in the position of receiving requests for more features than com=
plaints that implementations aren&#39;t delivering what the interface appea=
rs, at a casual glance,=C2=A0to offer.</div>
<div>=C2=A0</div><div>My view here is to defer consideration of this until =
later in the process.</div><div>=C2=A0</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border=
-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"=
>
<div dir=3D"ltr"><div><div>

<div><br></div><div>rectangle and rectangle_int should be replaced with a t=
emplate, instances of which are used in the api. This template along with p=
oint&lt;T&gt; should be in the top level std namespace and used throughout =
std when appropriate. Over time this will increase interoperability between=
 3rd party libraries as they start using them.</div>


<div><br></div></div></div></div></blockquote><div>=C2=A0</div><div>I defin=
itely agree as far as creating a point type. I need to think more about the=
 merits of templating point and rectangle; it seems obviously good but I&#3=
9;m unsure if it might not haunt us someday (not doing it might also haunt =
us; this is something I hope more people comment on either here or in Issaq=
uah). I&#39;m not sure about trying to hoist such types into std right now.=
 I think any decision to move these types out of drawing would be the purvi=
ew of LWG/LEWG.</div>
<div>=C2=A0</div><div>So I&#39;m adding a suggestion to create these class =
template types but I&#39;m not adding in a suggestion to=C2=A0move them to =
std. That&#39;d require a separate proposal. I would expect it to have a de=
tailed analysis of why they should be added to std,=C2=A0what effects addin=
g them directly to std can and should have, and how and whether those types=
 should interact with other Standard Library functionality (at a minimum).=
=C2=A0I also think it should be presented directly to LEWG, absent some ins=
truction from them to re-route it elsewhere. If someone writes such a propo=
sal and it is adopted, then we can always adopt those types in this library=
=C2=A0so long as the TS hasn&#39;t yet been published (even if it has, we c=
ould still probably work something out, though it&#39;d be harder).</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div></div>
<div>Similarly matrix should be called something like transform_matrix and =
inherit a generic std::matrix&lt;2,3&gt;, adding the affine transform speci=
fic setup methods as indicated.</div></div></div></div></blockquote><div>
=C2=A0</div><div>I think this is a good idea,=C2=A0but I&#39;m not adding i=
t as a suggestion because I think the creation a matrix type falls under=C2=
=A0SG6 and so should be presented via a proposal to them (assuming they are=
n&#39;t already considering it). If SG6 is working on or decides to work on=
 a matrix type, we should coordinate with=C2=A0them to follow its developme=
nt and make use of it. I did add in a &quot;question&quot; issue as a remin=
der to check with SG6 about this. If they don&#39;t take it up, I don&#39;t=
 see any reason for us to develop a generic matrix type when all we need is=
 a 2x3 matrix for affine transformations.</div>
<div>=C2=A0</div><div>Regardless, until we check with SG6 and hear back fro=
m them, I don&#39;t think there&#39;s anything for us to discuss just yet. =
But the matrix type we have now needs work so if they don&#39;t take it up =
then I think we should consider changing the name (in case they decide to t=
ake it up in the future) and should clean up the type (including adding app=
ropriate operator overloads, etc.). Someone else suggested that already and=
 I still need to go back and add that and other suggestions that were made =
before the reference implementation was published=C2=A0in to the issue trac=
ker.</div>
<div>=C2=A0</div><div>Incidentally, the standard suggests in a footnote tha=
t a hypothetical matrix class could be built up using the valarray class te=
mplate. We might want to consider doing that here if we are left to our own=
 devices in terms of the matrix type.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div><br>
</div><div>

If the to me a little bizzare class recangle_list exists region should have=
 a ctor from it.</div><div><br></div></div></div></div></blockquote><div>=
=C2=A0</div><div>Added as a suggestion. And I agree that it&#39;s a bizarre=
 type. I think it should probably be replaced with a vector&lt;rectangle&gt=
; and will be surprised if it isn&#39;t. I added that as a suggestion too.<=
/div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div></div>
<div>Is user_data_key and its use in device/surface really necessary to hav=
e?</div><div><br></div></div></div></div></blockquote><div>=C2=A0</div><div=
>As far as I&#39;m concerned, user_data_key (and the functionality it exist=
s to provide) should be obliterated. It&#39;s already a suggestion. But it&=
#39;s nice to know that others also question its usefulness.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div></div>
<div>Is shared_ptr semantics logical on device, really? It seems to me that=
 these are more in the vein of singletons (although there may be more than =
one). That is, you get a handle to it from somewhere central, which you the=
n never actually copy.</div>


<div><br></div></div></div></div></blockquote><div>=C2=A0</div><div>I hones=
tly don&#39;t know if there&#39;s a legitimate reason to have the device ty=
pe at all. I added a note to investigate it for possible=C2=A0elimination. =
During the discussion of that, if we decide it has a purpose we would then=
=C2=A0go on to decide its semantics. It&#39;s there because it came along a=
s part of the mechanical transformation. </div>
<div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>=
<div><div></div>
<div>The same goes for surface unless you can create subsurfaces as rects o=
n a parent surface, in which case reference counting is appropriate. Howeve=
r, I think that the reference counting should only be used between such sur=
face objects, not for all &quot;handles&quot; to any one particular subwind=
ow. This would mean that there would be no copy constructors or assignment =
operators. The ctor taking rect components is the one used to create a subs=
urface (and doing the reference counting).</div>


<div><br></div></div></div></div></blockquote><div>=C2=A0</div><div>You can=
 create subsurfaces from parent surfaces. Further,=C2=A0you can create an i=
mage_surface, make it the target of contextA, draw on it with contextA, and=
 then draw it to the target=C2=A0surface of contextB by creating a surface_=
pattern=C2=A0from it or by calling contextB::set_source_surface [which crea=
tes an ad hoc surface_pattern and sets it as the source pattern on the cont=
ext]. In other words, you can use image_surface objects as render targets (=
and this in turn is a key part of the pattern that=C2=A0allows you to imple=
ment multi-threaded graphics without stalling the thread that renders to yo=
ur output device). If you&#39;ll be in Issaquah, part of the presentation I=
&#39;ll be giving there is going to cover in depth the reason why I think t=
hat shared ownership semantics are the right way to go for these types. I&#=
39;ll also share my slides for the benefit of everyone who can&#39;t be the=
re. The rough-draft soundbite version is that shared ownership semantics gi=
ve you clean, modern-looking C++ without having everything wrapped in a sha=
red_ptr (ugly and a non-trivial possibility of misuse, especially by newcom=
ers to C++) while respecting the fact that deep copies of GPU resources wil=
l decimate performance and increase memory usage without any real benefit t=
o the end user (even if you wanted a copy of a texture, the best way to cre=
ate it is to draw it as a sprite to a render target).</div>
<div>=C2=A0</div><div>That said, shared ownership semantics are not a final=
 decision. I think they are justified here and will be making a formal case=
 for it, but the decision will ultimately rest in the hands of LEWG and SG1=
3. We may well end up with move-only semantics for GPU objects. I very much=
 doubt we would decide on value semantics due to the expense of copying GPU=
 resources. I added an issue for this for the sake of completeness.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div></div>
<div>There should be a ctor of surface which takes a rectangle&lt;double&gt=
; to describe the subsurface extent, not only one with four discrete ints. =
The use of double in this API is strange to me, or needs to be complemented=
 with a (more commonly used) API using int. The latter solution would be ap=
propriate in the case that using double implies a coordinate transform taki=
ng place before the subsurface is created. The hard thing about this is tha=
t if rotation or shear is included in the transform the subwindow can hardl=
y be created.</div>


<div><br></div></div></div></div></blockquote><div>=C2=A0</div><div>Oddly e=
nough, cairo states that the semantics for the function that the ctor deriv=
es from are only defined if you use whole units. Non whole units have not b=
een finalized as of yet. Given that, I don&#39;t see any reason to keep thi=
s as a double (what it is currently). That said, I&#39;m not adding it as a=
n issue simply because when the issue of what to do about the proposed poin=
t type and the existing rectangle and rectangle_int types is resolved, what=
 will follow will be rules transforming these sorts of functions into funct=
ions that take the appropriate resulting type. That was one of the transfor=
ms we intended to include (it&#39;s noted as a comment at the end of N3825)=
 but that I did not get around to including in N3888 (in part because I fig=
ured that people would want to discuss how we should define types such as p=
oint, rectangle, etc.). So rather than create types where none existed, I s=
tuck with cairo&#39;s types and transformed them. Since cairo has no point =
type, N3888 has no point type. But there will be one and when there is ther=
e will be a new transformation rule added to section 2 of the rules that wi=
ll cover it.</div>
<div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>=
<div><div></div>
<div>get_font_options should return a const ref to the internal font_option=
s object. I suspect that this is really a property of the device, but maybe=
 not given recent GPU developments.</div><div><br></div></div></div></div>
</blockquote><div>=C2=A0</div><div>This isn&#39;t the only place where this=
 &quot;out&quot; parameter pattern occurs. It definitely needs to be elimin=
ated wherever possible.=C2=A0I just did not want to do it on the first pass=
 since the transform=C2=A0rules are already quite complex and my hope is th=
at by=C2=A0having=C2=A0kept them as simple as possible, people will spot an=
y bugs or problems with them (as indeed people have; the rules call for vir=
tual dtors for base classes but it was a late rule and I did not get around=
 to changing=C2=A0it in the reference implementation until after publicatio=
n and so I also forgot to fix it in the Technical Specification section). B=
ut it&#39;s in the queue now so that when the time is right it will be deal=
t with.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div></div>


<div>It seems that the fallback resolution handling would be more appropria=
tely placed in device.</div><div><br></div><div>mark_dirty_rectange shoud b=
e available with a rectangle&lt;int&gt; as parameter. It seems inconsistent=
 that the subsurface creation ctor takes a double rect and the dirty functi=
on takes a int rect.</div>


<div><br></div><div>Is dirty rect handling really a function in this API at=
 all? It is tightly connected to the windowing system event handling, while=
 nothing else in this API really is.</div><div><br></div></div></div></div>
</blockquote><div>=C2=A0</div><div>The fallback resolution=C2=A0functionali=
ty has to do with non-raster output surfaces (e.g. printers, PDFs, SVGs). I=
 don&#39;t know of any good reason to exclude these as potential=C2=A0surfa=
ces that an implementation could choose to let a user draw to=C2=A0just now=
 so I see no reason to consider removing that functionality at this point. =
As such I&#39;m not adding an issue for it. There will be later passes thro=
ugh the API to remove functionality that wound up becoming unused or unnece=
ssary. The only things I&#39;m willing to put up for removal now are things=
 that are unambiguously unnecessary (e.g. the user_data_key stuff). The dir=
ty rect handling functionality is how cairo is informed that something else=
 was drawing to the surface. While we aren&#39;t standardizing cairo, havin=
g these function calls available to implementers could facilitate interop w=
here they choose to provide useful native handles to enable that. So it may=
 well have uses. If not, we&#39;ll eliminate it in a later pass.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div></div>
<div>write_to_png seems as a strange function here, as it sets one file for=
mat out in front of all others. Of course a image file read/write manager c=
ould be added to &quot;make file formats equal&quot; but I would put this i=
n the hands of 3rd party developers and instead concentrate on standardizin=
g an in-memory image memory class (placed in std or possibly its own sub-na=
mespace, but not in std::drawing at least).</div>


<div><br></div><div>The class image_surface seems to try to &quot;be&quot; =
this image memory, but only for the limited application of drawing in it. T=
his is really a pity as we have lots of other application areas where image=
 memories are important entities.</div>


<div><br></div><div>vector&lt;char&gt; is a very unsuitable way to specify =
image data as it can&#39;t be constructed without being inited to 0. There =
seems be great opposition against allowing vectors to default-construct the=
ir elements, I have argued for this many a time without any success. In the=
 absense of a real image memory class a char* + count API is actually much =
more appropriate as this allowd image memories from other libraries to be u=
sed. A stride parameter which is allowed to be larger than the number of by=
tes acutally required per line MUST be included or the value of this functi=
onality dwindles. This is true even with the vector based signatures.=C2=A0=
</div>
</div></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204)=
;border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div>

<div><br></div><div>The image_surface constructor taking a generator functi=
on doesn&#39;t need the closure parameter handling now that we have lambdas=
 (and functors).</div><div><br></div><div>The image_surface constructor fro=
m a filename indicates that there might be an underlying image format reade=
r system, which is not described. This seems not to be feasible at this tim=
e. Or it again implicitly refers to png files.</div>
</div></div></div></blockquote><div>=C2=A0</div><div>It comes from cairo&#3=
9;s PNG functionality. I&#39;m in favor of extending it to more image types=
 rather than eliminating it.</div><div>=C2=A0</div><div>You can call image_=
surface::get_data and write it out to whatever format you want. Or do whate=
ver you want with the resulting data for that matter.</div>
<div>=C2=A0</div><div>There&#39;s already an issue open to allow users dire=
ct access to pointers. I think having both is the best way to go since it l=
eave the choice of safety versus performance in the hands of the user. Also=
, you can construct a vector without zero initializing it provided you have=
 data to put in it already. The reference implementation does this in image=
_data::get_data. And if you don&#39;t have data to put in it right away, yo=
u can still call reserve on it. You&#39;re restricted in how you insert dat=
a=C2=A0when you=C2=A0use reserve rather than resize, but reserve will not z=
ero initialize the memory. The library already has functionality that tells=
 you the stride given a format and line width in pixels.</div>
<div>=C2=A0</div><div>I added an issue to verify that the void* closure par=
ameters are useless and then remove them from all of the functions that hav=
e them.</div><div>=C2=A0</div><div>Yeah, it&#39;s PNG again (the filename c=
tor). I have an email from the cairo mailing list to do something about thi=
s but haven&#39;t had a chance to turn it into an issue yet. The suggestion=
 there was to make it a static factory function (likely a member function) =
which has some appeal for me. I much prefer adding in support for more imag=
e types than removing the functionality regardless of how it is handled.</d=
iv>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div><div>

<div><br></div><div>A color class seems called for. Such an abstraction is =
present in most all drawing libraries, except apparently, Cairo. Again this=
 is one of those classes that are best placed directly in std, to be able t=
o reuse them in future extensions working with colors in other ways.</div>
</div></div></div></blockquote><div>=C2=A0</div><div>Right now I see no rea=
son for one. Further, the class has the potential to become a nightmare cla=
ss of doom as soon as it starts to flirt with concrete representations of c=
olors in pixel formats. If someone wants to draw up a proposal to add a col=
or class, they can. If it&#39;s going to go directly in std, it should be d=
irected to LEWG initially and only sent to SG13 if LEWG decides to do so.</=
div>
<div>=C2=A0</div><div>Don&#39;t get me wrong, I like color classes (even if=
 it&#39;s just an aggregate of const statics. How else am I supposed to kno=
w what values to use to get cornflower blue or any number of other named co=
lors that I&#39;m used to having available). And it may be that one will pr=
ove both useful and feasible here. But it&#39;s non-trivial and it&#39;s no=
t something that must exist to evaluate N3888 as a starting point for a 2D =
drawing library. So I&#39;m not adding it as an issue at this time. (Note: =
I&#39;m not the only person who can add issues so if someone feels that it =
absolutely must exist, they can add it and include a very good reason why i=
t must exist now because otherwise the chair may decide not to=C2=A0enterta=
in it).</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
>

<div><br></div><div>The unification of different types of brushes into patt=
ern class hierarchy seems promising. This should be unified with images, as=
 all of them are ways of presenting pixel values (color data) at regular 2d=
 positions, i.e. a raster. The raster_pattern type comes close to the image=
_memory I discussed above. Let&#39;s at least not have more than one type r=
epresenting a in-memory stored x,y indexed raster of pixels!</div>
</div></div></div></blockquote><div>=C2=A0</div><div>I&#39;m not going to a=
dd an issue that will mess with cairo&#39;s basic type system right now. I =
think that&#39;s something to discuss after there&#39;s a starting point. E=
ven then I would be against it. image_surface serves as a render target. A =
pattern does not and cannot.=C2=A0Cairo calls it a pattern, other libraries=
 use terms like brush. The concept of pattern/brush being distinct from sur=
face/texture=C2=A0is very much a part of the 2D libraries I&#39;m familiar =
with. Just because all data is bytes doesn&#39;t mean we should abandon goo=
d conceptual frameworks to in order to generalize concepts.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
>

<div><br></div><div>In the 3D world rasters are regularly called textures. =
This is today not really a good name for the actual data even in this appli=
cation as texture classes are also used for other things such as for instan=
ce bump maps. This actually goes beyond image data as such, but becomes a m=
atrix type class if generalized far enough.</div>


<div><br></div></div></div></div></blockquote><div>=C2=A0</div><div>The ter=
m texture isn&#39;t used anywhere in the drawing header. I&#39;m not quite =
sure what you&#39;re talking about here. Perhaps I&#39;m misunderstanding y=
ou?</div>
<div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>=
<div><div></div>
<div>To get around this mess it seems logical to follow the path that C++ h=
as taken in so many other areas, i.e. to templatize the methods and treat t=
he parameter type (now a T) like a concept. Thus it is the concept of an &q=
uot;image&quot; or &quot;raster&quot; that would be sdtandardized and then =
anything that complies to this concept can be drawn on or blitted onto some=
thing else. However, due to the plethora of storage formats for pixel data =
and the large sizes of images an efficient implementation of this is not ea=
sy to implement. I worked in a project which had implemented this and it wa=
s the module that had by far the longest compile times due to the large amo=
unt of template instantiations created. Note also that due to the dynamic n=
ature of image file loading there must be ways to dispatch to these templat=
e functions at run time depending on the user&#39;s selection of file.</div=
>


<div><br></div><div>The raster_source_pattern has a lot of callbacks and vo=
id* closure data that needs to be cleared out.</div></div></div></div></blo=
ckquote><div>=C2=A0</div><div>Yeah, raster_source_pattern is complicated. T=
he closures are wrapped up in the earlier issue re: closures. Most of the c=
allbacks are used only in some non-typical cases; only acquire is mandatory=
.. But I&#39;m not yet ready to throw out the functionality. It does have us=
es (customizations when dealing with a printing surface, for example) so I&=
#39;m not adding it as an issue at this time. We can remove it later if it =
still seems unnecessary then.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div><br>
</div><div>I&#39;m not particularly fond of the name &#39;context&#39; in t=
his case, as it is rather non-descriptive.</div>

<div><br></div></div></div></div></blockquote><div>=C2=A0</div><div>Bike sh=
ed. Also D3D11, OpenGL, and Quartz 2D use context in the names of their obj=
ects that perform drawing operations to a surface. SDL and=C2=A0openFramewo=
rks use it as a result of their ties with OpenGL. So I would not characteri=
ze it as non-descriptive. In fact, being a graphics::context object is the =
best, non-repetitive name for it in my opinion.</div>
<div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>=
<div><div></div>
<div>It is not so logical that the actual drawing methods are located in th=
e context, which mainly is a container for stateful drawing parameters. Whi=
le it is established practice (stemming I think from WIN32) to use a notion=
 of drawing context, I don&#39;t even think it really=C2=A0<span style=3D"f=
ont-size:13px">is</span><span style=3D"font-size:13px">=C2=A0sound object o=
riented design. I would much prefer that the actual drawing commands were m=
ethods on surface, and that these existed both in overloads with a context =
and without one (instead taking relevant parameters such as color and dash =
pattern for line drawing and brush for filling operations). This sort of un=
ites the ideas of stateful parameter storage and GDI+ style possibilities o=
f giving all parameters to each command. Both styles are useful! One reason=
 for having a drawing context object may be if it enhances thread safety (i=
..e. contexts are not thread safe per se byt serialize their (hidden) intera=
ctions with the underlying surface so that several worker threads can be gi=
ven parts of the same surface to draw on without problems). I don&#39;t how=
ever think that this is the intention of this proposal, is it?</span></div>


<div><br></div></div></div></div></blockquote><div>=C2=A0</div><div>As expl=
ained=C2=A0at the beginning of this reply, cairo&#39;s origins are in X11 a=
nd Win32 wasn&#39;t even contemplated at the time. Regardless, drawing meth=
ods on a context are, as you point out, established practice, and the most =
recent major library to adopt this=C2=A0was D3D11=C2=A0(D3D10 and earlier=
=C2=A0had drawing on=C2=A0done by the device itself). The context object is=
 central to the proposal. I have some issues filed to consider moving some =
categories of functionality=C2=A0off of it. But the transform you are askin=
g for requires a fundamentally new proposal.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div></div>
<div>I would like to see a simple way of rendering an image onto the surfac=
e without the convoluted procedure of first creating a pattern around the i=
mage, then setting this as the &quot;sourc _pattern&quot; of a context and =
then drawing a filled rectangle(!) to actually get the image data drawn.</d=
iv>


<div><br></div></div></div></div></blockquote><div>=C2=A0</div><div>Me too.=
=C2=A0This can easily be added later since it is already=C2=A0possible=C2=
=A0now.=C2=A0It&#39;s not central to evaluating N3888 as a starting point s=
o I&#39;m not filing an issue for it.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><div></div>
<div>Text output from unicode strings must be as simple as for 8 bit string=
s. Proper codepage handling must also be included for the 8 bit case I pres=
ume.</div><div><br></div></div></div></div></blockquote><div>=C2=A0</div><d=
iv>
The API as it stands deals in UTF-8 only. I&#39;d be willing to entertain U=
TF-16 or UTF-32, but codepages=C2=A0must=C2=A0die. I have no interest in di=
ving into the realm of locales and codepages for a modern library. Unless B=
jarne himself asks for it or my coauthors demand it, it&#39;s not going int=
o this proposal or anything based on it. Sorry.</div>
<div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>=
<div><div></div>
<div>Drawing commands need to exist in overloads with int coordinates. This=
 is the most common source of availability of data for drawing I think.</di=
v>

<div><br></div><div>Drawing commands should primarily work on Point data ra=
ther than discrete coordinate values, although overloads are a possibility.=
 Mainly to reduce typing when calling but also to increase eficiency as the=
 data is known to be placed together.</div>


<div><br></div><div>Polyline/polygon drawing should be included, using a ra=
nge-of-pointers concept.</div></div></div><div><br></div><div>The paint() v=
ersus stroke() methods which I assume mean to fill and/or outline closed fi=
gures subsequently drawn makes the interface even more stateful than Win32,=
 as you have both a possibility to set pattern and enable its use. On the o=
ther hand, compared to win32 and its followers, this gets rid of the need t=
o set an &quot;empty&quot; brush to avoid filling figures, which is an adva=
ntage. The double calls to get a patterned figure is however error prone. A=
lso, as I understand this, there is no shortcut to set a solid fill colour =
(you have to give the context a solid_colour_pattern to achieve the simples=
t of filled figures). Most other libraries has a shortcut for this called &=
quot;setbackgroundcolour&quot; or something like this.</div>


<div><br></div><div>As filled/stroked figures are so common I would contemp=
late encoding this in the method name even. FillRectangle() and StrokeRecta=
ngle() is very easy to understand... You loose some if you want to do both =
with the same rectangle, but in honest, how common is that?</div>


<div><br></div><div>The copy_page() and show_page() seem misplaced in a con=
text type of object, but if drawing commands were on the surface object the=
y would come more natural.</div><div><br></div></div></blockquote><div>
=C2=A0</div><div>copy_page and show_page are related to the functionality t=
hat allows surfaces to be things like printers, PDFs, etc. It stays for now=
 for the reasons previously described.</div><div>=C2=A0</div><div>The need =
for some sort of clear function that clears the surface to a specified colo=
r is definitely something to add in the=C2=A0future. This and the other thi=
ngs aren&#39;t things I&#39;m inclined to add to the (ever increasing) issu=
es list since they can be done later once we&#39;ve decided on whether N388=
8 or N3888 with modifications will be a suitable starting point for the lib=
rary.</div>
<div>=C2=A0</div><div>Thank you again for taking the time to make all these=
 recommendations!</div><div>=C2=A0</div><div>-Mike</div></div></div><div cl=
ass=3D"gmail_extra"><br></div></div>

<p></p>

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

--047d7b5d3b6e5b9e1304f1020632--

.

--f46d0444ee69ea86b504f10414e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 26, 2014 at 6:23 PM, Nicola Gigante <nicola.gigante@gmail.com>w=
rote:

>
> Il giorno 26/gen/2014, alle ore 21:38, Bengt Gustafsson <
> bengt.gustafsson@beamways.com> ha scritto:
>
> > Here are my comments. <cut>
>
> Hello everybody.
>
> I=E2=80=99m new to this list and I acknowledge that my opinion might not =
have a
> big weight if at all, but I have my two cents.
>
>
I try my best to judge opinions based on the ideas contained in them, not
the person expressing them.


I completely agree with Bengt regarding everything he said, but my point
> goes further. With modern C++
> gaining relevance thanks to new language features and new common
> practices, why on earth should the committee
> standardize an interface based on an old C library? I think that the idea
> of basing a standard rendering library
> on Cairo (or GDI, or any library designed before C++11 or even before
> C++98) is flawed by principle.
>
>
Cairo wasn't designed before C++98. It was started sometime in the
2002-2003 time frame as best I can tell. N3888 does not contemplate GDI.

I know of no major graphics library that was designed after C++11.


Differently from other standard library facilities or subsystems, a 2D
> drawing API cannot be designed by
> one or few men alone. To get it right, it needs enough field-testing, to
> be sure that:
> 1) the API is easy to use (in my opinion, the Qt drawing API is a
> reference point from this point of view),
> 2) it is flexible enough, given possible future uses and future hardware
> capabilities
> 3) it doesn=E2=80=99t impose artificial constraints, allowing the most ef=
ficient
> implementation across varying architectures and OSes.
>
> Because of this, proposing an interface (even if a modern, well thought
> interface), without actually having implemented it and
> made it used by actual users for enough time, is a bad idea.
>
>
You may wish to read N3791: http://isocpp.org/files/papers/n3791.html . Its
author is Beman Dawes, one of the founders of Boost and someone who has
been active in standardization for many years. In designing N3888 we took
his advice from N3791 to heart. It makes sense and it comes from someone
who has not only seen many things become standards but who has also seen
many things fail to become standards.

I have implemented this interface. The reference implementation is
available here: https://github.com/mikebmcl/N3888_RefImpl . I freely admit
that the API as it stands now is awkward. The point of N3888 is not to be
the standard but to propose a starting point that provides all the core
functionality people need from a 2D drawing library in a form that is
malleable enough to shape it into a clean, modern C++ API in the style of
the C++ Standard Library.

The reason for using a mechanical transformation of cairo as a starting
point is to address your second and third points above. Your first point is
one of the primary things that SG13 will be working on once we have agreed
upon a starting point.

As for Qt, I invite you to consider the number of dependencies that Qt has
on Qt. I considered and consciously rejected deriving an API from QPainter.
Not because it is bad; I think it is quite good. I rejected it because I
believed that trying to carve out the 2D drawing part of Qt without needing
to standardize most of the rest of Qt (or butcher the API to the point
where we'd be losing most of the benefits that Qt provides) would be
extremely difficult. To me, Qt is designed to be used with Qt. Take a look
at the QPainter API: http://qt-project.org/doc/qt-5/qpainter.html . Note
the QVector<T> and the QString and QImage and all the other Qt types. It's
a lot of baggage. Cairo, by contrast, is a graphics library. Period.

If you want to write a proposal based on QPainter or some other aspect of
Qt you can. Things only get standardized when someone decides to write a
proposal and put in the work of explaining it, defending it, accepting
valid criticisms of it, changing it, and so on until such time as it is at
last accepted as a standard. And there is no guarantee that it ever will be
accepted.


Anyway, should I have to answer my list of bullets, here it is:
> 1) Please make simple things simple, hard things possible.
>   i.e. We all want the highest flexibility, but I don=E2=80=99t want to c=
reate or
> retrieve 8 objects to draw a filled circle.
>

We will be working on that. The first step is to establish a starting
point. From there we can focus on turning it into a clean, modern API.



> 2) Please handle fonts in a modern way and flexible. A 2D drawing API is
> useless nowadays without strong typographic support.
> 3) This points out the convenience of a text-layout facility.
>

Handling fonts, text rendering, and typography in general is a hard
problem. We are going to do the best we can on this front, but understand
that A) N3888 is a starting point not a final destination; and B) the final
destination will still only be version 1. We are intentionally aiming at a
small scope for the reasons set forth in N3791. We will be doing our best
to craft a final API that is not final. In other words, one that can be
expanded in the future to provide more functionality based on what users of
the library tell us they want.

Also, I completely reject the statement that "[a] 2D drawing API is useless
nowadays without strong typographic support." Indeed, I contend that it
would be useful even with no typography. If I could write standard,
portable C++ code to do all of my 2D drawing and have it just work on
Windows, GNU/Linux, the various *BSD distributions, Mac OS X, iOS, Android,
Windows Phone, Blackberry, AIX, etc., and all I had to do was write
platform specific code for font management and text rendering, I would
still have saved myself a huge amount of work.


4) An extensible reading/writing facility for image formats is a must, not
> an option
>

I agree. See my responses to Bengt on this subject for more info as to why.



> 5) Don=E2=80=99t ignore platform differences. Giving access to native han=
dles is
> not sufficient. Make it possible to have, for example,
> a raster engine, an OpenGL engine, a D3D engine, etc=E2=80=A6
>

This is untenable. Native handles are a nice, proven abstraction for
exposing platform-specific functionality without being compelled to
standardize all of those platforms. Because if we had an OpenGL engine and
a D3D engine, etc., we would need to standardize those interfaces. Even
assuming that the Khronos Group and Microsoft both suddenly decided
to allow these technologies to be submitted for standardization, it would
still be a herculean task. With a horribly fragile result. The changes
between different versions of OpenGL and D3D are not trivial. Even if we
could standardize these things we would then be chained to them for the
indefinite future, forced to update the standard every time they made a
change or else fall woefully behind. For these reasons and more, even
contemplating a design that includes platform specifics is futile.


6) For the software engine, writing the spec to have (or make it easy to
> have) pixel-to-pixel portability across implementations is a must.
>

You can't even get pixel-to-pixel portability between different generations
of GPUs from the same manufacturer (though they have gotten much better in
recent years). Beyond stating that, I'm not really sure what point you were
trying to make. We standardize an interface. The interface has semantics
that define behaviors based on inputs. Implementers implement those
interfaces and (hopefully) comply with the semantics, thus giving the
results that the standard specifies. But we cannot compel implementers to
do anything. It's ultimately their responsibility to deliver what their
user base desires. So the best we can do is create something fun and
exciting that we really want to use and in turn promote it to other C++
users so that they want to use it too which in turn puts pressure on the
compiler vendors to provide what we are asking for.



> 7) Printing support is highly coupled with drawing, and it=E2=80=99s diff=
icult to
> get the API right. You need a complete interface to set
>    all the possible printing options out there, but with a connection wit=
h
> the underlying platform because in GUI code you want to make the
>    user choose them with the native interface (this means importing the
> settings from the native type that represent them, not to handle the
>

See my response to 5 above. It's up to implementers to choose whether to
support printing functionality at all and then to decide how to do it if
they do decide to.



> 8) Interoperability with the underlying platform is essential (again with
> a standard way to convert types that represents images, brushes,
>     colors, fonts etc=E2=80=A6 from the native type to the std:: ones).
>

This is one of the main purposes of native handles, those things that you
dismissed earlier as being not sufficient.



> 9) Please give us powerful mathematical and geometrical primitives (a wel=
l
> designed and efficient std::matrix and two point<T> and
>     rectangle<T> classes are not enough at all)
>

That is the domain of SG6 and LEWG. See generally
http://isocpp.org/std/the-committee . Many of the people involved with SG13
undoubtedly have good math backgrounds, but to find people who are the real
subject matter experts in this, you would turn to SG6. Standards don't
happen unless someone writes a proposal. If you believe these things need
to be standardized, start working on a proposal. If you need help, ask.
There are people who would be happy to help guide you through the process
of writing a proposal, though you need to be ready and willing to spend the
hundreds of hours that a proposal of the nature that you have asked for
would take. And, as mentioned above, willing to spend all of that time with
no guarantee that anything will ever come of it.


10) With regards of the previous two points, it would be even better if
> everything is abstracted with a trait system like the boost geometric l
>      library (but possibly less complex)
>

Someone else will have to address this point; I do not know if anyone has
ever proposed standardizing Boost's Geometry library and if so
what the status of any such effort is.



> 11) shared_ptr is good, but why do the API have to expose the memory
> managed object at all? Let=E2=80=99s face the users with RAII types that
>     opaquely handles everything.
>

In points 5 and 7 you are asking for exposure of all sorts of platform
specific functionality. Here you are saying bury everything in opaque
types. There is a logical inconsistency between these two positions. Object
lifetime and semantics matter regardless of what aspect of C++ someone is
discussing. When it comes to graphics, it matters even if it's not C++.
Why? Part of the reason is that GPUs are massively parallel computing
devices. They scream like banshees through incomprehensible numbers of
calculations every second. Certain operations can bring that vast machinery
to a screeching, bone-chilling halt. One of them is moving any non-trivial
quantity of data from the GPU to the CPU. Even if you avoid problems like
that, you can still hobble the GPU in other ways, such as
constantly recreating and destroying resources that it manages. So in a
graphics library, the semantics of a type that represents a GPU resource
matter a lot. If you want a clean, modern library that also has good
performance, getting these issues right is fundamental. Making the API look
pretty is fairly trivial by comparison.


12) Please investigate on an FP-like approach to compose drawing operations=
..
>   i.e. we have stroke() and fill(), make me compose them to stroke and
> fill and reuse the composition, in a way that it run faster than execute
>  two operations again.
>
>
FP? I'm afraid I'm not sure what you are referring to. Possible because
it's 3:46 in the morning and all that is coming to mind is floating point.



> Note that I=E2=80=99m not saying =E2=80=9CCairo doesn=E2=80=99t do any of=
 these=E2=80=9D, but even if the
> library itself have strong support for a lot of those points,
> the interface is still fundamentally old...
>
>
Cairo provides all of the functionality that we wanted from a 2D drawing
library. That's why we chose it. The mechanical transformation turns its C
API into a very rough C++ API. We think that this provides a good starting
point. It has a ways to go yet even if it is accepted as the starting
point. And accepting it as the starting point does not mean that the final
product will be accepted. N3888 should be judged on its merits as a
proposal for a starting point. If accepted, the final project will need to
be judged on its merits as a proposed TS. If it gets to that point (and I
hope that it does) I expect and, to the extent permissible, demand that it
be judged strictly. Nobody wins if we deliver something bad to C++
developers. So we will give it our all to make the best thing we can and
hope that the Committee ultimately deems it worthy. If not, I'll try again
because I believe in this effort.

-Mike

--=20

---=20
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-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-proposa=
ls/.

--f46d0444ee69ea86b504f10414e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><br></div><div class=3D"gma=
il_quote">On Sun, Jan 26, 2014 at 6:23 PM, Nicola Gigante <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:nicola.gigante@gmail.com" target=3D"_blank">nicola.g=
igante@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><br>
Il giorno 26/gen/2014, alle ore 21:38, Bengt Gustafsson &lt;<a href=3D"mail=
to:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsson@beamwa=
ys.com</a>&gt; ha scritto:<br>
<br>
&gt; Here are my comments. &lt;cut&gt;<br>
<br>
Hello everybody.<br>
<br>
I=E2=80=99m new to this list and I acknowledge that my opinion might not ha=
ve a big weight if at all, but I have my two cents.<br>
<br></blockquote><div>=C2=A0</div><div>I try my best=C2=A0to judge opinions=
 based on the ideas contained in them, not the person expressing them.</div=
><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid">



I completely agree with Bengt regarding everything he said, but my point go=
es further. With modern C++<br>
gaining relevance thanks to new language features and new common practices,=
 why on earth should the committee<br>
standardize an interface based on an old C library? I think that the idea o=
f basing a standard rendering library<br>
on Cairo (or GDI, or any library designed before C++11 or even before C++98=
) is flawed by principle.<br>
<br></blockquote><div>=C2=A0</div><div>Cairo wasn&#39;t designed before C++=
98.=C2=A0It=C2=A0was started sometime in the 2002-2003 time frame as best I=
 can tell. N3888 does not contemplate GDI.</div><div>=C2=A0</div>
<div>I know of no major graphics library that was designed after C++11.=C2=
=A0</div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(20=
4,204,204);border-left-width:1px;border-left-style:solid">



Differently from other standard library facilities or subsystems, a 2D draw=
ing API cannot be designed by<br>
one or few men alone. To get it right, it needs enough field-testing, to be=
 sure that:<br>
1) the API is easy to use (in my opinion, the Qt drawing API is a reference=
 point from this point of view),<br>
2) it is flexible enough, given possible future uses and future hardware ca=
pabilities<br>
3) it doesn=E2=80=99t impose artificial constraints, allowing the most effi=
cient implementation across varying architectures and OSes.<br>
<br>
Because of this, proposing an interface (even if a modern, well thought int=
erface), without actually having implemented it and<br>
made it used by actual users for enough time, is a bad idea.<br>
<br></blockquote><div>=C2=A0</div><div>You may wish to read N3791: <a href=
=3D"http://isocpp.org/files/papers/n3791.html">http://isocpp.org/files/pape=
rs/n3791.html</a> . Its author is Beman Dawes, one of the founders of Boost=
 and someone who has been active in standardization for many years. In desi=
gning N3888 we took his advice from N3791 to heart. It makes sense and it c=
omes from someone who has not only seen many things become standards but wh=
o has also seen many things fail to become standards.</div>
<div>=C2=A0</div><div>I have implemented this interface.=C2=A0The reference=
 implementation is available here:=C2=A0<a href=3D"https://github.com/mikeb=
mcl/N3888_RefImpl">https://github.com/mikebmcl/N3888_RefImpl</a> . I freely=
 admit that the API as it stands now is awkward. The point of N3888 is not =
to be the standard but to propose a starting point that provides all the co=
re functionality people need from a 2D drawing library in a form that is ma=
lleable enough to shape it into a clean, modern C++ API in the style of the=
 C++ Standard Library.</div>
<div>=C2=A0</div><div>The reason for using a mechanical transformation of c=
airo as a starting point is to address=C2=A0your second and third=C2=A0poin=
ts above. Your first point is one of the=C2=A0primary things that=C2=A0SG13=
 will be working on once we have agreed upon a starting point.</div>
<div>=C2=A0</div><div>As for Qt, I invite you to consider the number of dep=
endencies that Qt has on Qt. I considered and consciously=C2=A0rejected der=
iving an API from QPainter. Not because it is bad; I think it is quite good=
..=C2=A0I rejected it=C2=A0because I believed that trying to carve out the 2=
D drawing part of Qt without needing to standardize most of the rest of Qt =
(or butcher the API to the point where we&#39;d be losing most of the benef=
its that Qt provides) would be extremely difficult. To me, Qt is designed t=
o be used with Qt. Take a look at the QPainter API: <a href=3D"http://qt-pr=
oject.org/doc/qt-5/qpainter.html">http://qt-project.org/doc/qt-5/qpainter.h=
tml</a> . Note the QVector&lt;T&gt; and the QString and QImage and all the =
other Qt types. It&#39;s a lot of baggage. Cairo, by contrast, is a graphic=
s library. Period.</div>
<div>=C2=A0</div><div>If you want to write a proposal based on QPainter or =
some other aspect of Qt you can. Things only get standardized when someone =
decides to write a proposal and put in the work of explaining it, defending=
 it, accepting valid criticisms of it, changing it, and so on until such ti=
me as it is at last accepted as a standard. And there is no guarantee that =
it ever will be accepted.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid">
Anyway, should I have to answer my list of bullets, here it is:<br>
1) Please make simple things simple, hard things possible.<br>
=C2=A0 i.e. We all want the highest flexibility, but I don=E2=80=99t want t=
o create or retrieve 8 objects to draw a filled circle.<br></blockquote><di=
v>=C2=A0</div><div>We will be working on that. The first step is to=C2=A0es=
tablish a starting point. From there we can focus on=C2=A0turning it into a=
 clean, modern API.</div>
<div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
2) Please handle fonts in a modern way and flexible. A 2D drawing API is us=
eless nowadays without strong typographic support.<br>
3) This points out the convenience of a text-layout facility.<br></blockquo=
te><div>=C2=A0</div><div>Handling fonts, text rendering, and typography in =
general=C2=A0is a hard problem. We are going to do the best we can on this=
=C2=A0front, but understand that=C2=A0A) N3888 is a starting point not a fi=
nal destination; and B)=C2=A0the=C2=A0final destination will still only be =
version 1. We are intentionally=C2=A0aiming at a small scope for the reason=
s set forth in N3791. We will be doing our best to=C2=A0craft a final API t=
hat is not final. In other words, one that can be expanded in the future to=
 provide more functionality based on=C2=A0what users of the library tell us=
 they want.</div>
<div>=C2=A0</div><div>Also, I completely reject the statement that &quot;[a=
] 2D drawing API is useless nowadays without strong typographic support.&qu=
ot; Indeed, I contend that it would be useful even with no typography. If I=
 could write standard, portable C++ code to do all of my 2D drawing and hav=
e it just work on Windows, GNU/Linux, the various *BSD distributions, Mac O=
S X, iOS, Android, Windows Phone, Blackberry, AIX, etc., and all I had to d=
o was write platform specific code for font management and text rendering, =
I would still have saved myself a huge amount of work.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid">
4) An extensible reading/writing facility for image formats is a must, not =
an option<br></blockquote><div>=C2=A0</div><div>I agree. See my responses=
=C2=A0to=C2=A0Bengt on this subject for more info as to why.</div><div>=C2=
=A0</div><div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
5) Don=E2=80=99t ignore platform differences. Giving access to native handl=
es is not sufficient. Make it possible to have, for example,<br>
a raster engine, an OpenGL engine, a D3D engine, etc=E2=80=A6<br></blockquo=
te><div>=C2=A0</div><div>This is untenable. Native=C2=A0handles are a nice,=
 proven abstraction for exposing platform-specific=C2=A0functionality witho=
ut being compelled to standardize all of those platforms. Because if we had=
 an OpenGL engine and a D3D engine, etc., we would need to standardize thos=
e interfaces. Even assuming=C2=A0that the Khronos Group and Microsoft both=
=C2=A0suddenly decided to=C2=A0allow these=C2=A0technologies to be submitte=
d for standardization, it would still be a herculean task. With a horribly =
fragile result. The changes between different versions of OpenGL and D3D ar=
e not trivial. Even if we could standardize these things we would then be c=
hained to them for the indefinite future, forced to update the standard eve=
ry time they made a change or else fall woefully behind. For these reasons =
and more, even contemplating a design that includes platform specifics is f=
utile.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid">
6) For the software engine, writing the spec to have (or make it easy to ha=
ve) pixel-to-pixel portability across implementations is a must.<br></block=
quote><div>=C2=A0</div><div>You can&#39;t even get pixel-to-pixel portabili=
ty between different generations of GPUs from the same manufacturer (though=
 they have gotten much better in recent years). Beyond stating that, I&#39;=
m not really sure what point you were trying to make. We standardize an int=
erface. The interface has semantics that define behaviors based on inputs. =
Implementers implement those interfaces and=C2=A0(hopefully) comply with th=
e semantics, thus giving=C2=A0the results that=C2=A0the standard specifies.=
 But=C2=A0we cannot=C2=A0compel implementers to do anything. It&#39;s ultim=
ately their responsibility to deliver what their user base desires. So the =
best we can do is create something fun and exciting that we really want to =
use and in turn promote it to other C++ users=C2=A0so that they want to use=
 it too which in turn puts pressure on the compiler vendors to provide=C2=
=A0what=C2=A0we are asking for.</div>
<div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
7) Printing support is highly coupled with drawing, and it=E2=80=99s diffic=
ult to get the API right. You need a complete interface to set<br>
=C2=A0 =C2=A0all the possible printing options out there, but with a connec=
tion with the underlying platform because in GUI code you want to make the<=
br>
=C2=A0 =C2=A0user choose them with the native interface (this means importi=
ng the settings from the native type that represent them, not to handle the=
<br></blockquote><div>=C2=A0</div><div>See my response to 5 above.=C2=A0It&=
#39;s up to=C2=A0implementers to choose whether to support printing functio=
nality at all and then=C2=A0to decide how to do it if they do decide to.</d=
iv>
<div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
8) Interoperability with the underlying platform is essential (again with a=
 standard way to convert types that represents images, brushes,<br>
=C2=A0 =C2=A0 colors, fonts etc=E2=80=A6 from the native type to the std:: =
ones).<br></blockquote><div>=C2=A0</div><div>This is one of the main purpos=
es of native handles, those things=C2=A0that you dismissed earlier as being=
 not sufficient.</div><div>
=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid">
9) Please give us powerful mathematical and geometrical primitives (a well =
designed and efficient std::matrix and two point&lt;T&gt; and<br>
=C2=A0 =C2=A0 rectangle&lt;T&gt; classes are not enough at all)<br></blockq=
uote><div>=C2=A0</div><div>That is the domain of SG6 and LEWG. See generall=
y <a href=3D"http://isocpp.org/std/the-committee">http://isocpp.org/std/the=
-committee</a> .=C2=A0Many of the people involved with SG13 undoubtedly hav=
e good math backgrounds, but to find people who are the real subject matter=
 experts in this, you would turn to SG6. Standards don&#39;t happen unless =
someone writes a proposal. If you believe these things need to be standardi=
zed, start working on a proposal. If you need help, ask. There are people w=
ho would be happy to help guide you through the process of writing a propos=
al, though you need to be ready and willing to spend the hundreds of hours =
that a proposal of the nature that you have asked for would take. And, as m=
entioned above, willing to spend all of that time with no guarantee that an=
ything will ever come of it.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid">
10) With regards of the previous two points, it would be even better if eve=
rything is abstracted with a trait system like the boost geometric l<br>
=C2=A0 =C2=A0 =C2=A0library (but possibly less complex)<br></blockquote><di=
v>=C2=A0</div><div>Someone else=C2=A0will have to address this point; I do =
not know if anyone has ever proposed standardizing Boost&#39;s Geometry lib=
rary and if so what=C2=A0the=C2=A0status of any such effort is.</div>
<div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
11) shared_ptr is good, but why do the API have to expose the memory manage=
d object at all? Let=E2=80=99s face the users with RAII types that<br>
=C2=A0 =C2=A0 opaquely handles everything.<br></blockquote><div>=C2=A0</div=
><div>In points 5 and 7 you are asking for exposure of all sorts of=C2=A0pl=
atform specific functionality. Here you are saying bury everything in opaqu=
e types. There is a logical inconsistency between these two positions. Obje=
ct lifetime=C2=A0and semantics matter regardless of what aspect of C++ some=
one is discussing. When it comes to graphics, it matters even if it&#39;s n=
ot C++. Why? Part of the reason is that GPUs are massively parallel computi=
ng devices. They scream like banshees through incomprehensible numbers of c=
alculations every second. Certain operations can bring that vast machinery =
to a screeching, bone-chilling halt. One of them is=C2=A0moving any non-tri=
vial quantity of data from=C2=A0the=C2=A0GPU to the CPU. Even if you avoid =
problems like that, you can still hobble the GPU in other ways, such as con=
stantly=C2=A0recreating and destroying resources that it manages. So in a g=
raphics library, the semantics of a type that represents a GPU resource mat=
ter a lot. If you want a clean, modern library that also has good performan=
ce, getting these issues right is fundamental. Making the API look pretty i=
s fairly trivial by comparison.</div>
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid">
12) Please investigate on an FP-like approach to compose drawing operations=
..<br>
=C2=A0 i.e. we have stroke() and fill(), make me compose them to stroke and=
 fill and reuse the composition, in a way that it run faster than execute =
=C2=A0two operations again.<br>
<br></blockquote><div>=C2=A0</div><div>FP? I&#39;m afraid I&#39;m not sure =
what you are referring to. Possible because it&#39;s 3:46 in the morning an=
d all that is coming to mind is=C2=A0floating point.</div><div>=C2=A0</div>=
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
Note that I=E2=80=99m not saying =E2=80=9CCairo doesn=E2=80=99t do any of t=
hese=E2=80=9D, but even if the library itself have strong support for a lot=
 of those points,<br>
the interface is still fundamentally old...<br>
<br></blockquote><div>=C2=A0</div></div><div class=3D"gmail_extra">Cairo pr=
ovides all of the functionality that we wanted from a 2D drawing library. T=
hat&#39;s why we chose it. The mechanical transformation turns its C API in=
to a very rough C++ API. We think that this provides a good starting point.=
 It has a ways to go yet even if it is accepted as the starting point. And =
accepting it as the starting point does not mean that the final product wil=
l be accepted. N3888 should be judged on its merits as a proposal for a sta=
rting point. If accepted, the final project will need to be judged on its m=
erits as a proposed TS. If it gets to that point (and I hope that it does) =
I expect and, to the extent permissible, demand that it be judged strictly.=
 Nobody wins if we deliver something bad to C++ developers. So we will give=
 it our all to make the best thing we can and hope that the Committee ultim=
ately deems it worthy. If not, I&#39;ll try again because I believe in this=
 effort.</div>
<div class=3D"gmail_extra">=C2=A0</div><div class=3D"gmail_extra">-Mike</di=
v><div class=3D"gmail_extra">=C2=A0</div><div class=3D"gmail_extra"><br></d=
iv></div>

<p></p>

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

--f46d0444ee69ea86b504f10414e4--

.

--001a11363910cb819204f1063f7f
Content-Type: text/plain; charset=UTF-8

On Tue, Jan 28, 2014 at 10:02 AM, Michael McLaughlin <mikebmcl@gmail.com>wrote:

>
> 12) Please investigate on an FP-like approach to compose drawing
>> operations.
>>   i.e. we have stroke() and fill(), make me compose them to stroke and
>> fill and reuse the composition, in a way that it run faster than execute
>>  two operations again.
>>
>>
> FP? I'm afraid I'm not sure what you are referring to. Possible because
> it's 3:46 in the morning and all that is coming to mind is floating point.
>

I believe FP here means Functional Programming (style).

--

---
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/.

--001a11363910cb819204f1063f7f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Jan 28, 2014 at 10:02 AM, Michael McLaughlin <span dir=3D"ltr">&lt;=
<a href=3D"mailto:mikebmcl@gmail.com" target=3D"_blank">mikebmcl@gmail.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid">

12) Please investigate on an FP-like approach to compose drawing operations=
..<br>
=C2=A0 i.e. we have stroke() and fill(), make me compose them to stroke and=
 fill and reuse the composition, in a way that it run faster than execute =
=C2=A0two operations again.<br>
<br></blockquote><div>=C2=A0</div></div><div>FP? I&#39;m afraid I&#39;m not=
 sure what you are referring to. Possible because it&#39;s <span class=3D"a=
Bn" tabindex=3D"0"><span class=3D"aQJ">3:46</span></span> in the morning an=
d all that is coming to mind is=C2=A0floating point.</div>
</blockquote></div><br>I believe FP here means Functional Programming (styl=
e).</div></div>

<p></p>

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

--001a11363910cb819204f1063f7f--

.

On Tue, Jan 28, 2014 at 4:35 AM, Michael McLaughlin <mikebmcl@gmail.com> wrote:
>

[snip]

>> rectangle and rectangle_int should be replaced with a template, instances
>> of which are used in the api. This template along with point<T> should be in
>> the top level std namespace and used throughout std when appropriate. Over
>> time this will increase interoperability between 3rd party libraries as they
>> start using them.
>
> I definitely agree as far as creating a point type. I need to think more
> about the merits of templating point and rectangle; it seems obviously
> good

IMO the coordinate space should be parameterizable by algorithms, which
makes rectangles and point obviously templates. But with the current OO
API this doesn't make sense. So I really don't see how the current API
can, through evolutionary steps, get anywhere near C++ Standard quality.
Have you evaluated Boost.GIL? I couldn't see it mentioned in the proposal.

[snip]

>> The same goes for surface unless you can create subsurfaces as rects on a
>> parent surface, in which case reference counting is appropriate. However, I
>> think that the reference counting should only be used between such surface
>> objects, not for all "handles" to any one particular subwindow. This would
>> mean that there would be no copy constructors or assignment operators. The
>> ctor taking rect components is the one used to create a subsurface (and
>> doing the reference counting).
>>
>
> You can create subsurfaces from parent surfaces. Further, you can create an
> image_surface, make it the target of contextA, draw on it with contextA, and
> then draw it to the target surface of contextB by creating a surface_pattern
> from it or by calling contextB::set_source_surface [which creates an ad hoc
> surface_pattern and sets it as the source pattern on the context]. In other
> words, you can use image_surface objects as render targets (and this in turn
> is a key part of the pattern that allows you to implement multi-threaded
> graphics without stalling the thread that renders to your output device). If
> you'll be in Issaquah, part of the presentation I'll be giving there is
> going to cover in depth the reason why I think that shared ownership
> semantics are the right way to go for these types. I'll also share my slides
> for the benefit of everyone who can't be there. The rough-draft soundbite
> version is that shared ownership semantics give you clean, modern-looking
> C++ without having everything wrapped in a shared_ptr (ugly and a
> non-trivial possibility of misuse, especially by newcomers to C++) while
> respecting the fact that deep copies of GPU resources will decimate
> performance and increase memory usage without any real benefit to the end
> user (even if you wanted a copy of a texture, the best way to create it is
> to draw it as a sprite to a render target).

I don't buy this let's remove the copy-constructor because it is expensive.
If the user doesn't want to copy, he can just not copy it, if he wants to
copy, then why is the class irregular?

> That said, shared ownership semantics are not a final decision. I think they
> are justified here and will be making a formal case for it, but the decision
> will ultimately rest in the hands of LEWG and SG13. We may well end up with
> move-only semantics for GPU objects. I very much doubt we would decide on
> value semantics due to the expense of copying GPU resources. I added an
> issue for this for the sake of completeness.

I really don't get it what's the problem with expensive copying. It is only
expensive when they are used. It is also expensive to copy a list with
a million elements, but it is still copyable nevertheless.

>> There should be a ctor of surface which takes a rectangle<double> to
>> describe the subsurface extent, not only one with four discrete ints. The
>> use of double in this API is strange to me, or needs to be complemented with
>> a (more commonly used) API using int. The latter solution would be
>> appropriate in the case that using double implies a coordinate transform
>> taking place before the subsurface is created. The hard thing about this is
>> that if rotation or shear is included in the transform the subwindow can
>> hardly be created.
>
> Oddly enough, cairo states that the semantics for the function that the ctor
> derives from are only defined if you use whole units. Non whole units have
> not been finalized as of yet. Given that, I don't see any reason to keep
> this as a double (what it is currently). That said, I'm not adding it as an
> issue simply because when the issue of what to do about the proposed point
> type and the existing rectangle and rectangle_int types is resolved, what
> will follow will be rules transforming these sorts of functions into
> functions that take the appropriate resulting type. That was one of the
> transforms we intended to include (it's noted as a comment at the end of
> N3825) but that I did not get around to including in N3888 (in part because
> I figured that people would want to discuss how we should define types such
> as point, rectangle, etc.). So rather than create types where none existed,
> I stuck with cairo's types and transformed them. Since cairo has no point
> type, N3888 has no point type. But there will be one and when there is there
> will be a new transformation rule added to section 2 of the rules that will
> cover it.

Or we could have a Point concept instead.

>> To get around this mess it seems logical to follow the path that C++ has
>> taken in so many other areas, i.e. to templatize the methods and treat the
>> parameter type (now a T) like a concept. Thus it is the concept of an
>> "image" or "raster" that would be sdtandardized and then anything that
>> complies to this concept can be drawn on or blitted onto something else.
>> However, due to the plethora of storage formats for pixel data and the large
>> sizes of images an efficient implementation of this is not easy to
>> implement. I worked in a project which had implemented this and it was the
>> module that had by far the longest compile times due to the large amount of
>> template instantiations created. Note also that due to the dynamic nature of
>> image file loading there must be ways to dispatch to these template
>> functions at run time depending on the user's selection of file.

Was this project, by any chance, open source?

> -Mike
>
> --


Regards,
--
Felipe Magno de Almeida

--

---
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/.

.

On 2014-01-28 04:02, Michael McLaughlin wrote:
> As for Qt, I invite you to consider the number of dependencies that Qt ha=
s
> on Qt. I considered and consciously rejected deriving an API from QPainte=
r.
> Not because it is bad; I think it is quite good. I rejected it because I
> believed that trying to carve out the 2D drawing part of Qt without needi=
ng
> to standardize most of the rest of Qt (or butcher the API to the point
> where we'd be losing most of the benefits that Qt provides) would be
> extremely difficult. To me, Qt is designed to be used with Qt. Take a loo=
k
> at the QPainter API: http://qt-project.org/doc/qt-5/qpainter.html . Note
> the QVector<T> and the QString and QImage and all the other Qt types. It'=
s
> a lot of baggage. Cairo, by contrast, is a graphics library. Period.

The worst of that is related to text rendering=C2=B9. If you're excising th=
at=20
anyway, it's not an issue. The rest I suspect is either support classes=20
that should be part of the API anyway (e.g. QImage) or readily ported=20
(e.g. QVector<T> -> std::vector<T>).

Sacrificing quality of API for ease of porting an existing=20
implementation seems like a dubious trade-off IMHO. If it is generally=20
felt that Qt represents a good API design "except for all those Qt=20
classes", then IMHO the right thing to do is do a mass-rename of Qt=20
classes to STL classes and propose the result as the API.

(=C2=B9 for good reason; as mentioned, text rendering, especially when you=
=20
start getting into localization intricacies, is hard.)

> On Sun, Jan 26, 2014 at 6:23 PM, Nicola Gigante wrote:
>> 5) Don=E2=80=99t ignore platform differences. Giving access to native ha=
ndles is
>> not sufficient. Make it possible to have, for example,
>> a raster engine, an OpenGL engine, a D3D engine, etc=E2=80=A6
>
> This is untenable. Native handles are a nice, proven abstraction for
> exposing platform-specific functionality without being compelled to
> standardize all of those platforms.

As I understood it, the point here is that the API should be agnostic to=20
the engine. Ideally to the extent that the engine can be changed without=20
recompiling code. This is the case with e.g. Qt, which allows swapping=20
out the underlying engine via an environment variable.

Exposing too much of the underlying guts is an invitation to write=20
non-portable code.

(That said, I may be reading my own expectations to that comment and in=20
fact, agreeing with you and disagreeing with Nicola.)

> Because if we had an OpenGL engine and
> a D3D engine, etc., we would need to standardize those interfaces.

Not at all; see above. The drawing API is standard, the implementation=20
is not and is free to deal with non-standardized details of the=20
underlying engine technology. If anything, the opposite is true;=20
exposing internal details harms the "standard-ness" of the API without=20
the underlying engine itself being standardized. (And worse, invites=20
applications to write platform-specific code, which is rather counter to=20
the objective.)

>> 8) Interoperability with the underlying platform is essential (again wit=
h
>> a standard way to convert types that represents images, brushes,
>>      colors, fonts etc=E2=80=A6 from the native type to the std:: ones).

Really? Why?

I've written a number of Qt and/or OpenGL applications, and can't think=20
of any case in which I've needed to deal directly with e.g. X objects.

Per above, this is actively *harmful* to writing portable code and IMHO=20
should be strongly discouraged. Even on a single platform, it precludes=20
(or at least, makes much more difficult) engine agnosticism.

An API that allows using the exact same compiled code to perform=20
comparable drawing operations regardless of the output device (e.g.=20
screen, buffer, printer) and engine is IMHO much preferable.

--=20
Matthew

--=20

---=20
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-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-proposa=
ls/.

.

On 28 January 2014 16:44, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> Sacrificing quality of API for ease of porting an existing implementation
> seems like a dubious trade-off IMHO. If it is generally felt that Qt

It's a trade-off to get an implementable starting point that can then be worked
towards a higher-quality API. The point is having an implementation available
from day one.

> represents a good API design "except for all those Qt classes", then IMHO
> the right thing to do is do a mass-rename of Qt classes to STL classes and
> propose the result as the API.

The question is whether QPainter as an API _starting point_ is better
than Cairo.

>>> 8) Interoperability with the underlying platform is essential (again with
>>> a standard way to convert types that represents images, brushes,
>>>      colors, fonts etc... from the native type to the std:: ones).
> Really? Why?

In order to access platform-specific facilities that are not supported by the
portable API. Yes, that access is platform-specific and results in non-portable
code. However, it can be essential for interoperating with platform-specific
facilities, which sometimes are necessary.

> I've written a number of Qt and/or OpenGL applications, and can't think of
> any case in which I've needed to deal directly with e.g. X objects.

I can. I have written Qt applications that needed to use eg. XDamage to
get a live thumbnail of running applications. And for a window list, that
meant dealing with X window handles, too.

> Per above, this is actively *harmful* to writing portable code and IMHO
> should be strongly discouraged. Even on a single platform, it precludes (or
> at least, makes much more difficult) engine agnosticism.

Yes, it's harmful to writing portable code, but it is in contrast more harmful
to say that this API of ours allows no interoperability with platform-specific
facilities. The users who need such "escape hatches" to interoperate
with platform-specific facilities cannot use this portable API at all.

The native handles in the standard thread library are there for a reason.
That reason applies similarly to a standard drawing library.

--

---
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/.

.

--nextPart1663592.vR6aL1r8oT
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On ter=E7a-feira, 28 de janeiro de 2014 09:44:08, Matthew Woehlke wrote=
:
> The worst of that is related to text rendering=B9. If you're excising=
 that
> anyway, it's not an issue. The rest I suspect is either support class=
es
> that should be part of the API anyway (e.g. QImage) or readily ported=

> (e.g. QVector<T> -> std::vector<T>).

> (=B9 for good reason; as mentioned, text rendering, especially when y=
ou
> start getting into localization intricacies, is hard.)

Text rendering and localisation represent probably 80% or more of the i=
nstall=20
size of combined QtCore and QtGui, due to the CLDR and Unicode tables i=
n Qt=20
and in ICU. And then we have external dependencies like fontconfig and =
freetype=20
to get fonts, harfbuzz to get shaping correct, classes like=20
QTextBoundaryFinder to find where to do word-splitting...

This part of the discussion is quite heated. What Michael proposed is t=
o limit=20
the required font and text handling capabilities to what Cairo offers i=
n the=20
toyfont, though implementations would be welcome to do the whole thing.=


> > This is untenable. Native handles are a nice, proven abstraction fo=
r
> > exposing platform-specific functionality without being compelled to=

> > standardize all of those platforms.
>=20
> As I understood it, the point here is that the API should be agnostic=
 to
> the engine. Ideally to the extent that the engine can be changed with=
out
> recompiling code. This is the case with e.g. Qt, which allows swappin=
g
> out the underlying engine via an environment variable.
>=20
> Exposing too much of the underlying guts is an invitation to write
> non-portable code.

Which might be necessary. Not providing the native handles limits the=20=

usefulness to only the API that is provided, no extension possible.=20

Qt provides the native handles for the widgets, for example, and that a=
llows=20
applications like window managers and desktop fixtures to be developed.=
 They'd=20
be impossible without platform-specific code.

PS: the swapping of the engine was removed in Qt 5 because there's only=
 one=20
engine left.

> I've written a number of Qt and/or OpenGL applications, and can't thi=
nk
> of any case in which I've needed to deal directly with e.g. X objects=
..
>
> Per above, this is actively *harmful* to writing portable code and IM=
HO
> should be strongly discouraged. Even on a single platform, it preclud=
es
> (or at least, makes much more difficult) engine agnosticism.

Discouraged, yes. But still necessary: those applications might be few =
and far=20
between, but they exist.

--=20
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

--nextPart1663592.vR6aL1r8oT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBS5976M/XwBW70U1gRArJQAJsEDy1R+hbsGpcYdtOS2EEtIIOs6ACfSUyq
fXwNHm1Yqmuy/P39V6YArrg=
=nzzd
-----END PGP SIGNATURE-----

--nextPart1663592.vR6aL1r8oT--


.

--Apple-Mail=_6EDAB0A9-5180-4303-B71B-DC79D9D4ED52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=windows-1252


Il giorno 28/gen/2014, alle ore 10:02, Michael McLaughlin <mikebmcl@gmail.c=
om> ha scritto:

> =20
> I try my best to judge opinions based on the ideas contained in them, not=
 the person expressing them.

Of course, thank you :)

> =20
>=20
> I completely agree with Bengt regarding everything he said, but my point =
goes further. With modern C++
> gaining relevance thanks to new language features and new common practice=
s, why on earth should the committee
> standardize an interface based on an old C library? I think that the idea=
 of basing a standard rendering library
> on Cairo (or GDI, or any library designed before C++11 or even before C++=
98) is flawed by principle.
>=20
> =20
> Cairo wasn't designed before C++98. It was started sometime in the 2002-2=
003 time frame as best I can tell. N3888 does not contemplate GDI.

I=92m afraid I=92ve badly explained myself here. I know cairo has not been =
designed before. GDI was that =93pre-C++98=94 library I was=20
referring to, and I know it=92s not mentioned in your proposal. All I wante=
d to say was that =93generally=94 I don=92t agree very much on the concept
of taking a previous library and reshape it. I know, as you have said a few=
 times, that this is only a starting point, don=92t worry about this.

> =20
> I know of no major graphics library that was designed after C++11.=20
> =20
That=92s exactly the point here. Nobody have implemented a new design in ye=
ars.
The new language features _may_ allow design patterns and kinds of interact=
ions between the library and user code
that are unknown at this time. Starting from a pre-existing API and simply =
=93restyling=94 it could hide those possibilities. Not that
I don=92t understand that having a working implementation from the start is=
 equally important.


>=20
> Differently from other standard library facilities or subsystems, a 2D dr=
awing API cannot be designed by
> one or few men alone. To get it right, it needs enough field-testing, to =
be sure that:
> 1) the API is easy to use (in my opinion, the Qt drawing API is a referen=
ce point from this point of view),
> 2) it is flexible enough, given possible future uses and future hardware =
capabilities
> 3) it doesn=92t impose artificial constraints, allowing the most efficien=
t implementation across varying architectures and OSes.
>=20
> Because of this, proposing an interface (even if a modern, well thought i=
nterface), without actually having implemented it and
> made it used by actual users for enough time, is a bad idea.
>=20
>=20

Here, I=92ve never intended to say that the people involved don=92t have ex=
perience in implementing those things! It was only a general=20
statement.

> =20
> As for Qt, I invite you to consider the number of dependencies that Qt ha=
s on Qt. I considered and consciously rejected deriving an API from QPainte=
r. Not because it is bad; I think it is quite good. I rejected it because I=
 believed that trying to carve out the 2D drawing part of Qt without needin=
g to standardize most of the rest of Qt (or butcher the API to the point wh=
ere we'd be losing most of the benefits that Qt provides) would be extremel=
y difficult. To me, Qt is designed to be used with Qt. Take a look at the Q=
Painter API: http://qt-project.org/doc/qt-5/qpainter.html . Note the QVecto=
r<T> and the QString and QImage and all the other Qt types. It's a lot of b=
aggage. Cairo, by contrast, is a graphics library. Period.
> =20
> If you want to write a proposal based on QPainter or some other aspect of=
 Qt you can. Things only get standardized when someone decides to write a p=
roposal and put in the work of explaining it, defending it, accepting valid=
 criticisms of it, changing it, and so on until such time as it is at last =
accepted as a standard. And there is no guarantee that it ever will be acce=
pted.
> =20

Please note that the QtGui module (which in Qt 5.x does not contain widgets=
, only drawing code) depends only on QtCore, which is nothing=20
more than an alternative to basic facilities offered by the standard librar=
y and the STL (threading, strings, containers, ecc=85).
There are no other dependencies. I don=92t see any difference in an API fun=
ction drawPolygon(QVector<QPoint> points) and
the corresponding draw_polygon(std::array_view<std::point> points) (for exa=
mple).=20

Anyway I was not proposing to take Qt as the starting point of a proposal i=
n the same way you took Cairo. What I was suggesting was to
take it as a reference from a point of view of ease of use and flexibility,=
 which I admit is a matter of taste, but it seems a widely common taste.

> =20
> 2) Please handle fonts in a modern way and flexible. A 2D drawing API is =
useless nowadays without strong typographic support.
> 3) This points out the convenience of a text-layout facility.
> =20
> Handling fonts, text rendering, and typography in general is a hard probl=
em. We are going to do the best we can on this front, but understand that A=
) N3888 is a starting point not a final destination; and B) the final desti=
nation will still only be version 1. We are intentionally aiming at a small=
 scope for the reasons set forth in N3791. We will be doing our best to cra=
ft a final API that is not final. In other words, one that can be expanded =
in the future to provide more functionality based on what users of the libr=
ary tell us they want.
> =20
> Also, I completely reject the statement that "[a] 2D drawing API is usele=
ss nowadays without strong typographic support." Indeed, I contend that it =
would be useful even with no typography. If I could write standard, portabl=
e C++ code to do all of my 2D drawing and have it just work on Windows, GNU=
/Linux, the various *BSD distributions, Mac OS X, iOS, Android, Windows Pho=
ne, Blackberry, AIX, etc., and all I had to do was write platform specific =
code for font management and text rendering, I would still have saved mysel=
f a huge amount of work.

I agree with you that my statement was a little exaggerated. But please dis=
tinguish between font rendering and text layout. The first, if done,
must be done well. Support for a variety of font formats and fully-featured=
 font rendering (kerning, rtl ecc=85) is essential, if=20
the concept of =93font=94 is supported at all. If the alternative is to sup=
port text rendering in a primitive way, it=92s better to not support it at =
all
and let users use already available libraries to handle it.

>  =20
> 5) Don=92t ignore platform differences. Giving access to native handles i=
s not sufficient. Make it possible to have, for example,
> a raster engine, an OpenGL engine, a D3D engine, etc=85
> =20
> This is untenable. Native handles are a nice, proven abstraction for expo=
sing platform-specific functionality without being compelled to standardize=
 all of those platforms. Because if we had an OpenGL engine and a D3D engin=
e, etc., we would need to standardize those interfaces. Even assuming that =
the Khronos Group and Microsoft both suddenly decided to allow these techno=
logies to be submitted for standardization, it would still be a herculean t=
ask. With a horribly fragile result. The changes between different versions=
 of OpenGL and D3D are not trivial. Even if we could standardize these thin=
gs we would then be chained to them for the indefinite future, forced to up=
date the standard every time they made a change or else fall woefully behin=
d. For these reasons and more, even contemplating a design that includes pl=
atform specifics is futile.
> =20

I would have been mad to propose the standardization of OpenGL or D3D inter=
faces!! What I meant was another thing, in the spirit
of what Qt means by =93engine=94. The drawing API is standard. The underlyi=
ng engine is what actually performs the drawing. The raster=20
engine implements everything on the CPU thus not requiring additional hardw=
are resources (see the point 6). The OpenGL engine uses=20
OpenGL to draw, the D3D engine uses D3D. The OpenVG engine uses OpenVG. My =
idea was to make the API relying on an underlying
unspecified engine, mandating implementors to provide at least a raster eng=
ine and letting them providing all the engines that the underlying
platform may allow (for example there could be a Quartz engine on OS X and =
a GDI engine on Windows). Then the user can chose if using
the =93default=94 engine, which the implementation can chose as the best pe=
rforming depending of runtime availability, for example, of GPU acceleratio=
n, or to chose a specific engine, being conscious of portability issues. It=
=92s a reasoning very similar to the container allocators=20
infrastructure, if you think about it.=20
Note that a design like this does not expose platform specifics at all. Ind=
eed it hides details, by allowing the user to use native resources
without the need to interfacing directly with them. Note that engines are a=
lso separated from the concept of =93drawing device=94.
With a raster or OpenGL engine you can careless choose to draw to an image =
or to an on-screen framebuffer. Qt even have classes
like QPicture, which simply =93records" drawing commands instead of render =
them, allowing to save the graphics to vectorial formats
like PDF or the like.

All of this is not an original idea. It=92s just how the Qt drawing API is =
designed from the modularity point of view. This kind of =93inspiration=94
is what I meant by referring to Qt in the previous points, not a mechanical=
 transformation of its APIs.

>=20
> 6) For the software engine, writing the spec to have (or make it easy to =
have) pixel-to-pixel portability across implementations is a must.
> =20
> You can't even get pixel-to-pixel portability between different generatio=
ns of GPUs from the same manufacturer (though they have gotten much better =
in recent years). Beyond stating that, I'm not really sure what point you w=
ere trying to make. We standardize an interface. The interface has semantic=
s that define behaviors based on inputs. Implementers implement those inter=
faces and (hopefully) comply with the semantics, thus giving the results th=
at the standard specifies. But we cannot compel implementers to do anything=
.. It's ultimately their responsibility to deliver what their user base desi=
res. So the best we can do is create something fun and exciting that we rea=
lly want to use and in turn promote it to other C++ users so that they want=
 to use it too which in turn puts pressure on the compiler vendors to provi=
de what we are asking for.
> =20

My point started with =93For the software engine=94. What I meant was the r=
aster engine I=92ve talked about at the previous point. pixel-to-pixel
portability is what a lot of drawing software (from TeX to the Qt raster en=
gine itself) actually achieves by not relying on hardware and=20
implementing rendering algorithms by software. Note that not using the GPU =
might sound slow, but a software fallback is going to be needed=20
anyway by portable standard libraries (like libstdc++ or libc++) that are n=
ot tied on a particular platform. It might also be the only choice=20
available on embedded platforms (or simply if I want to draw something from=
 a command line or server-side process and I can=92t link to OpenGL or what=
ever). From that to allowing users to specify =93I _want_ my graphic to be =
rendered in software=94 and making at=20
least some guarantees about results, the trip is short.

> =20
> 8) Interoperability with the underlying platform is essential (again with=
 a standard way to convert types that represents images, brushes,
>     colors, fonts etc=85 from the native type to the std:: ones).
> =20
> This is one of the main purposes of native handles, those things that you=
 dismissed earlier as being not sufficient.

It depends on what you mean by handles. If you mean =93any platform specifi=
c type that represents anything=94, ok. But the concept is
vague. A HANDLE type on Windows is an handle of course, but if you=92re on =
OS X, an instance of CFImage is an handle? a QBrush object is=20
an handle?

I think a lot of users of this library will use it in already existing code=
 bases. What i would like, is a way to shade slowly from using
the platform specific code to the standard API in the most seamless way pos=
sible. Or what if you have a mature, big code base of imaging
algorithms, and you want to use the results with the new standard library? =
The only way to do that is to allow=20
the integration of previously used types. Letting users to go to and from s=
td::drawing::image to CFImage, for example. Of course, the specific=20
conversions cannot be ruled by the standard! What is needed by the standard=
 is a generic architecture that is able to use user=92s types for
the representation of basic concepts like images, fonts, colors, brushes, a=
nd geometric primitives, like as with a system of traits types.

It=92s nothing new, it=92s only the same spirit of the STL. It provides vec=
tors, but generic algorithms work also on the user=92s MyOwnVector, given
the interface is compatible. At the same time, libraries like Qt provides t=
heir own QVector, but have made it compatible with the STL=20
algorithms!

> =20
> =20
> 9) Please give us powerful mathematical and geometrical primitives (a wel=
l designed and efficient std::matrix and two point<T> and
>     rectangle<T> classes are not enough at all)
> =20
> That is the domain of SG6 and LEWG. See generally http://isocpp.org/std/t=
he-committee . Many of the people involved with SG13 undoubtedly have good =
math backgrounds, but to find people who are the real subject matter expert=
s in this, you would turn to SG6.

The this point reduces to the triviality of suggesting collaboration betwee=
n groups.

> Standards don't happen unless someone writes a proposal. If you believe t=
hese things need to be standardized, start working on a proposal. If you ne=
ed help, ask. There are people who would be happy to help guide you through=
 the process of writing a proposal, though you need to be ready and willing=
 to spend the hundreds of hours that a proposal of the nature that you have=
 asked for would take. And, as mentioned above, willing to spend all of tha=
t time with no guarantee that anything will ever come of it.
> =20

I=92m not that masochist :P Nevertheless I=92m happy to provide my opinions=
 for what it=92s worth, and I think that incremental improving is better=20
than forking proposals like linux distros ;)

>=20
> 10) With regards of the previous two points, it would be even better if e=
verything is abstracted with a trait system like the boost geometric l
>      library (but possibly less complex)
> =20
> Someone else will have to address this point; I do not know if anyone has=
 ever proposed standardizing Boost's Geometry library and if so what the st=
atus of any such effort is.
> =20
I was not proposing to standardize boost geometry. What I=92m talking about=
, again, is to take its =93principles=94 as reference. In this case I=92m=
=20
talking about the concept of providing geometric algorithms that work on an=
y user-provided =93point=94 or =93rectangle=94 or =93polygon=94 types, whil=
e
providing concrete types for these concepts anyway. Again, this is nothing =
but the general philosophy of the STL.


> 11) shared_ptr is good, but why do the API have to expose the memory mana=
ged object at all? Let=92s face the users with RAII types that
>     opaquely handles everything.
> =20
> In points 5 and 7 you are asking for exposure of all sorts of platform sp=
ecific functionality. Here you are saying bury everything in opaque types. =
There is a logical inconsistency between these two positions.
Here I was only saying that, if some objects have shared ownership semantic=
s, in my opinion it's better to handle the ownership management=20
opaquely instead of exposing shared_ptr in the API, and I think to understa=
nd that it=92s already this way anyway. It has nothing to do with
platform specific functionalities.

> 12) Please investigate on an FP-like approach to compose drawing operatio=
ns.
>   i.e. we have stroke() and fill(), make me compose them to stroke and fi=
ll and reuse the composition, in a way that it run faster than execute  two=
 operations again.
>=20
> =20
> FP? I'm afraid I'm not sure what you are referring to. Possible because i=
t's 3:46 in the morning and all that is coming to mind is floating point.
> =20

Sorry, I meant a Functional Programming-like approach. What I mean was to b=
e able to compose drawing operations, or batching groups of=20
operations in a composable way. It was an abstract point more than a concre=
te proposal. This is simply one of those things that I=92ve talked
about at the beginning of the email: undiscovered possibilities. Nobody has=
 designed a drawing API that can leverage lambdas because
C and C++ didn=92t have lambdas. Lambdas are only an example anyway, so don=
=92t ask me how they fit in the drawing library. I=92m only
saying I think it=92s worth spending some time investigating those possibil=
ities to be able, maybe, to end up with something really innovative.

>=20
> -Mike
> =20
Good bye,
Nicola

--=20

---=20
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-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-proposa=
ls/.

--Apple-Mail=_6EDAB0A9-5180-4303-B71B-DC79D9D4ED52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>Il giorn=
o 28/gen/2014, alle ore 10:02, Michael McLaughlin &lt;<a href=3D"mailto:mik=
ebmcl@gmail.com">mikebmcl@gmail.com</a>&gt; ha scritto:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra">&nbsp;</div><div class=3D"gmail_quote"><div>I try my b=
est&nbsp;to judge opinions based on the ideas contained in them, not the pe=
rson expressing them.</div></div></div></blockquote><div><br></div><div>Of =
course, thank you :)</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><div>&nbsp;</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">



I completely agree with Bengt regarding everything he said, but my point go=
es further. With modern C++<br>
gaining relevance thanks to new language features and new common practices,=
 why on earth should the committee<br>
standardize an interface based on an old C library? I think that the idea o=
f basing a standard rendering library<br>
on Cairo (or GDI, or any library designed before C++11 or even before C++98=
) is flawed by principle.<br>
<br></blockquote><div>&nbsp;</div><div>Cairo wasn't designed before C++98.&=
nbsp;It&nbsp;was started sometime in the 2002-2003 time frame as best I can=
 tell. N3888 does not contemplate GDI.</div></div></div></blockquote><div><=
br></div><div><div>I=92m afraid I=92ve badly explained myself here. I know =
cairo has not been designed before. GDI was that =93pre-C++98=94 library I =
was&nbsp;</div><div>referring to, and I know it=92s not mentioned in your p=
roposal. All I wanted to say was that =93generally=94 I don=92t agree very =
much on the concept</div><div>of taking a previous library and reshape it. =
I know, as you have said a few times, that this is only a starting point, d=
on=92t worry about this.</div></div><br><blockquote type=3D"cite"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div>&nbsp;</div>
<div>I know of no major graphics library that was designed after C++11.&nbs=
p;</div><div>&nbsp;</div></div></div></blockquote><div>That=92s exactly the=
 point here. Nobody have implemented a new design in years.</div><div>The n=
ew language features _may_ allow design patterns and kinds of interactions =
between the library and user code</div><div>that are unknown at this time. =
Starting from a pre-existing API and simply =93restyling=94 it could hide t=
hose possibilities. Not that</div><div>I don=92t understand that having a w=
orking implementation from the start is equally important.</div><div><br></=
div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_quot=
e"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid">



Differently from other standard library facilities or subsystems, a 2D draw=
ing API cannot be designed by<br>
one or few men alone. To get it right, it needs enough field-testing, to be=
 sure that:<br>
1) the API is easy to use (in my opinion, the Qt drawing API is a reference=
 point from this point of view),<br>
2) it is flexible enough, given possible future uses and future hardware ca=
pabilities<br>
3) it doesn=92t impose artificial constraints, allowing the most efficient =
implementation across varying architectures and OSes.<br>
<br>
Because of this, proposing an interface (even if a modern, well thought int=
erface), without actually having implemented it and<br>
made it used by actual users for enough time, is a bad idea.<br>
<br></blockquote><div><br></div></div></div></blockquote><div><br></div><di=
v>Here, I=92ve never intended to say that the people involved don=92t have =
experience in implementing those things! It was only a general&nbsp;</div><=
div>statement.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div cla=
ss=3D"gmail_quote">
<div>&nbsp;</div><div>As for Qt, I invite you to consider the number of dep=
endencies that Qt has on Qt. I considered and consciously&nbsp;rejected der=
iving an API from QPainter. Not because it is bad; I think it is quite good=
..&nbsp;I rejected it&nbsp;because I believed that trying to carve out the 2=
D drawing part of Qt without needing to standardize most of the rest of Qt =
(or butcher the API to the point where we'd be losing most of the benefits =
that Qt provides) would be extremely difficult. To me, Qt is designed to be=
 used with Qt. Take a look at the QPainter API: <a href=3D"http://qt-projec=
t.org/doc/qt-5/qpainter.html">http://qt-project.org/doc/qt-5/qpainter.html<=
/a> . Note the QVector&lt;T&gt; and the QString and QImage and all the othe=
r Qt types. It's a lot of baggage. Cairo, by contrast, is a graphics librar=
y. Period.</div>
<div>&nbsp;</div><div>If you want to write a proposal based on QPainter or =
some other aspect of Qt you can. Things only get standardized when someone =
decides to write a proposal and put in the work of explaining it, defending=
 it, accepting valid criticisms of it, changing it, and so on until such ti=
me as it is at last accepted as a standard. And there is no guarantee that =
it ever will be accepted.</div>
<div>&nbsp;</div></div></div></blockquote><div><br></div><div>Please note t=
hat the QtGui module (which in Qt 5.x does not contain widgets, only drawin=
g code) depends only on QtCore, which is nothing&nbsp;</div><div>more than =
an alternative to basic facilities offered by the standard library and the =
STL (threading, strings, containers, ecc=85).</div><div>There are no other =
dependencies. I don=92t see any difference in an API function drawPolygon(Q=
Vector&lt;QPoint&gt; points) and</div><div>the corresponding draw_polygon(s=
td::array_view&lt;std::point&gt; points) (for example).&nbsp;</div><div><br=
></div><div>Anyway I was not proposing to take Qt as the starting point of =
a proposal in the same way you took Cairo. What I was suggesting was to</di=
v><div>take it as a reference from a point of view of ease of use and flexi=
bility, which I admit is a matter of taste, but it seems a widely common ta=
ste.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmai=
l_quote"><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid; position: static; z-i=
ndex: auto;">
2) Please handle fonts in a modern way and flexible. A 2D drawing API is us=
eless nowadays without strong typographic support.<br>
3) This points out the convenience of a text-layout facility.<br></blockquo=
te><div>&nbsp;</div><div>Handling fonts, text rendering, and typography in =
general&nbsp;is a hard problem. We are going to do the best we can on this&=
nbsp;front, but understand that&nbsp;A) N3888 is a starting point not a fin=
al destination; and B)&nbsp;the&nbsp;final destination will still only be v=
ersion 1. We are intentionally&nbsp;aiming at a small scope for the reasons=
 set forth in N3791. We will be doing our best to&nbsp;craft a final API th=
at is not final. In other words, one that can be expanded in the future to =
provide more functionality based on&nbsp;what users of the library tell us =
they want.</div>
<div>&nbsp;</div><div>Also, I completely reject the statement that "[a] 2D =
drawing API is useless nowadays without strong typographic support." Indeed=
, I contend that it would be useful even with no typography. If I could wri=
te standard, portable C++ code to do all of my 2D drawing and have it just =
work on Windows, GNU/Linux, the various *BSD distributions, Mac OS X, iOS, =
Android, Windows Phone, Blackberry, AIX, etc., and all I had to do was writ=
e platform specific code for font management and text rendering, I would st=
ill have saved myself a huge amount of work.</div>
</div></div></blockquote><div><br></div><div>I agree with you that my state=
ment was a little exaggerated. But please distinguish between font renderin=
g and text layout. The first, if done,</div><div>must be done well. Support=
 for a variety of font formats and fully-featured font rendering (kerning, =
rtl ecc=85) is essential, if&nbsp;</div><div>the concept of =93font=94 is s=
upported at all. If the alternative is to support text rendering in a primi=
tive way, it=92s better to not support it at all</div><div>and let users us=
e already available libraries to handle it.</div><br><blockquote type=3D"ci=
te"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>&nbsp;&nbsp;</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid; position: static; z-index: auto;">
5) Don=92t ignore platform differences. Giving access to native handles is =
not sufficient. Make it possible to have, for example,<br>
a raster engine, an OpenGL engine, a D3D engine, etc=85<br></blockquote><di=
v>&nbsp;</div><div>This is untenable. Native&nbsp;handles are a nice, prove=
n abstraction for exposing platform-specific&nbsp;functionality without bei=
ng compelled to standardize all of those platforms. Because if we had an Op=
enGL engine and a D3D engine, etc., we would need to standardize those inte=
rfaces. Even assuming&nbsp;that the Khronos Group and Microsoft both&nbsp;s=
uddenly decided to&nbsp;allow these&nbsp;technologies to be submitted for s=
tandardization, it would still be a herculean task. With a horribly fragile=
 result. The changes between different versions of OpenGL and D3D are not t=
rivial. Even if we could standardize these things we would then be chained =
to them for the indefinite future, forced to update the standard every time=
 they made a change or else fall woefully behind. For these reasons and mor=
e, even contemplating a design that includes platform specifics is futile.<=
/div>
<div>&nbsp;</div></div></div></blockquote><div><br></div><div>I would have =
been mad to propose the standardization of OpenGL or D3D interfaces!! What =
I meant was another thing, in the spirit</div><div>of what Qt means by =93e=
ngine=94. The drawing API is standard. The underlying engine is what actual=
ly performs the drawing. The raster&nbsp;</div><div>engine implements every=
thing on the CPU thus not requiring additional hardware resources (see the =
point 6). The OpenGL engine uses&nbsp;</div><div>OpenGL to draw, the D3D en=
gine uses D3D. The OpenVG engine uses OpenVG. My idea was to make the API r=
elying on an underlying</div><div>unspecified engine, mandating implementor=
s to provide at least a raster engine and letting them providing all the en=
gines that the underlying</div><div>platform may allow (for example there c=
ould be a Quartz engine on OS X and a GDI engine on Windows). Then the user=
 can chose if using</div><div>the =93default=94 engine, which the implement=
ation can chose as the best performing depending of runtime availability, f=
or example, of GPU acceleration, or to chose a specific engine, being consc=
ious of portability issues. It=92s a reasoning very similar to the containe=
r allocators&nbsp;</div><div>infrastructure, if you think about it.&nbsp;</=
div>Note that a design like this does not expose platform specifics at all.=
 Indeed it hides details, by allowing the user to use native resources</div=
><div>without the need to interfacing directly with them. Note that engines=
 are also separated from the concept of =93drawing device=94.</div><div>Wit=
h a raster or OpenGL engine you can careless choose to draw to an image or =
to an on-screen framebuffer. Qt even have classes</div><div>like QPicture, =
which simply =93records" drawing commands instead of render them, allowing =
to save the graphics to vectorial formats</div><div>like PDF or the like.</=
div><div><br></div><div>All of this is not an original idea. It=92s just ho=
w the Qt drawing API is designed from the modularity point of view. This ki=
nd of =93inspiration=94</div><div>is what I meant by referring to Qt in the=
 previous points, not a mechanical transformation of its APIs.</div><div><b=
r><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_quote"><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:=
1px;border-left-style:solid">
6) For the software engine, writing the spec to have (or make it easy to ha=
ve) pixel-to-pixel portability across implementations is a must.<br></block=
quote><div>&nbsp;</div><div>You can't even get pixel-to-pixel portability b=
etween different generations of GPUs from the same manufacturer (though the=
y have gotten much better in recent years). Beyond stating that, I'm not re=
ally sure what point you were trying to make. We standardize an interface. =
The interface has semantics that define behaviors based on inputs. Implemen=
ters implement those interfaces and&nbsp;(hopefully) comply with the semant=
ics, thus giving&nbsp;the results that&nbsp;the standard specifies. But&nbs=
p;we cannot&nbsp;compel implementers to do anything. It's ultimately their =
responsibility to deliver what their user base desires. So the best we can =
do is create something fun and exciting that we really want to use and in t=
urn promote it to other C++ users&nbsp;so that they want to use it too whic=
h in turn puts pressure on the compiler vendors to provide&nbsp;what&nbsp;w=
e are asking for.</div>
<div>&nbsp;</div></div></div></blockquote><div><br></div><div>My point star=
ted with =93For the software engine=94. What I meant was the raster engine =
I=92ve talked about at the previous point. pixel-to-pixel</div><div>portabi=
lity is what a lot of drawing software (from TeX to the Qt raster engine it=
self) actually achieves by not relying on hardware and&nbsp;</div><div>impl=
ementing rendering algorithms by software. Note that not using the GPU migh=
t sound slow, but a software fallback is going to be needed&nbsp;</div><div=
>anyway by portable standard libraries (like libstdc++ or libc++) that are =
not tied on a particular platform. It might also be the only choice&nbsp;</=
div><div>available on embedded platforms (or simply if I want to draw somet=
hing from a command line or server-side process and I can=92t link to OpenG=
L or whatever). From that to allowing users to specify =93I _want_ my graph=
ic to be rendered in software=94 and making at&nbsp;</div><div>least some g=
uarantees about results, the trip is short.</div><div><br></div><blockquote=
 type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>&nbsp;</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid; position: static; z-index: auto;">
8) Interoperability with the underlying platform is essential (again with a=
 standard way to convert types that represents images, brushes,<br>
&nbsp; &nbsp; colors, fonts etc=85 from the native type to the std:: ones).=
<br></blockquote><div>&nbsp;</div><div>This is one of the main purposes of =
native handles, those things&nbsp;that you dismissed earlier as being not s=
ufficient.</div><div>
</div></div></div></blockquote><div><br></div><div>It depends on what you m=
ean by handles. If you mean =93any platform specific type that represents a=
nything=94, ok. But the concept is</div><div>vague. A HANDLE type on Window=
s is an handle of course, but if you=92re on OS X, an instance of CFImage i=
s an handle? a QBrush object is&nbsp;</div><div>an handle?</div><div><br></=
div><div>I think a lot of users of this library will use it in already exis=
ting code bases. What i would like, is a way to shade slowly from using</di=
v><div>the platform specific code to the standard API in the most seamless =
way possible. Or what if you have a mature, big code base of imaging</div><=
div>algorithms, and you want to use the results with the new standard libra=
ry? The only way to do that is to allow&nbsp;</div><div>the integration of =
previously used types. Letting users to go to and from std::drawing::image =
to CFImage, for example. Of course, the specific&nbsp;</div><div>conversion=
s cannot be ruled by the standard! What is needed by the standard is a gene=
ric architecture that is able to use user=92s types for</div><div>the repre=
sentation of basic concepts like images, fonts, colors, brushes, and geomet=
ric primitives, like as with a system of traits types.</div><div><br></div>=
<div>It=92s nothing new, it=92s only the same spirit of the STL. It provide=
s vectors, but generic algorithms work also on the user=92s MyOwnVector, gi=
ven</div><div>the interface is compatible. At the same time, libraries like=
 Qt provides their own QVector, but have made it compatible with the STL&nb=
sp;</div><div>algorithms!</div><br><blockquote type=3D"cite"><div dir=3D"lt=
r"><div class=3D"gmail_quote"><div>&nbsp;</div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid">
9) Please give us powerful mathematical and geometrical primitives (a well =
designed and efficient std::matrix and two point&lt;T&gt; and<br>
&nbsp; &nbsp; rectangle&lt;T&gt; classes are not enough at all)<br></blockq=
uote><div>&nbsp;</div><div>That is the domain of SG6 and LEWG. See generall=
y <a href=3D"http://isocpp.org/std/the-committee">http://isocpp.org/std/the=
-committee</a> .&nbsp;Many of the people involved with SG13 undoubtedly hav=
e good math backgrounds, but to find people who are the real subject matter=
 experts in this, you would turn to SG6. </div></div></div></blockquote><di=
v><br></div>The this point reduces to the triviality of suggesting collabor=
ation between groups.</div><div><br><blockquote type=3D"cite"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div>Standards don't happen unless someone w=
rites a proposal. If you believe these things need to be standardized, star=
t working on a proposal. If you need help, ask. There are people who would =
be happy to help guide you through the process of writing a proposal, thoug=
h you need to be ready and willing to spend the hundreds of hours that a pr=
oposal of the nature that you have asked for would take. And, as mentioned =
above, willing to spend all of that time with no guarantee that anything wi=
ll ever come of it.</div>
<div>&nbsp;</div></div></div></blockquote><div><br></div><div>I=92m not tha=
t masochist :P Nevertheless I=92m happy to provide my opinions for what it=
=92s worth, and I think that incremental improving is better&nbsp;</div><di=
v>than forking proposals like linux distros ;)</div><br><blockquote type=3D=
"cite"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex=
;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style=
:solid">
10) With regards of the previous two points, it would be even better if eve=
rything is abstracted with a trait system like the boost geometric l<br>
&nbsp; &nbsp; &nbsp;library (but possibly less complex)<br></blockquote><di=
v>&nbsp;</div><div>Someone else&nbsp;will have to address this point; I do =
not know if anyone has ever proposed standardizing Boost's Geometry library=
 and if so what&nbsp;the&nbsp;status of any such effort is.</div>
<div>&nbsp;</div></div></div></blockquote>I was not proposing to standardiz=
e boost geometry. What I=92m talking about, again, is to take its =93princi=
ples=94 as reference. In this case I=92m&nbsp;</div><div>talking about the =
concept of providing geometric algorithms that work on any user-provided =
=93point=94 or =93rectangle=94 or =93polygon=94 types, while</div><div>prov=
iding concrete types for these concepts anyway. Again, this is nothing but =
the general philosophy of the STL.</div><div><br><br><blockquote type=3D"ci=
te"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color=
:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
11) shared_ptr is good, but why do the API have to expose the memory manage=
d object at all? Let=92s face the users with RAII types that<br>
&nbsp; &nbsp; opaquely handles everything.<br></blockquote><div>&nbsp;</div=
><div>In points 5 and 7 you are asking for exposure of all sorts of&nbsp;pl=
atform specific functionality. Here you are saying bury everything in opaqu=
e types. There is a logical inconsistency between these two positions. </di=
v></div></div></blockquote><div><div>Here I was only saying that, if some o=
bjects have shared ownership semantics, in my opinion it's better to handle=
 the ownership management&nbsp;</div><div>opaquely instead of exposing shar=
ed_ptr in the API, and I think to understand that it=92s already this way a=
nyway. It has nothing to do with</div><div>platform specific functionalitie=
s.</div></div></div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid; position: static; z-ind=
ex: auto;">
12) Please investigate on an FP-like approach to compose drawing operations=
..<br>
&nbsp; i.e. we have stroke() and fill(), make me compose them to stroke and=
 fill and reuse the composition, in a way that it run faster than execute &=
nbsp;two operations again.<br>
<br></blockquote><div>&nbsp;</div><div>FP? I'm afraid I'm not sure what you=
 are referring to. Possible because it's 3:46 in the morning and all that i=
s coming to mind is&nbsp;floating point.</div><div>&nbsp;</div></div></div>=
</blockquote><div><br></div><div>Sorry, I meant a Functional Programming-li=
ke approach. What I mean was to be able to compose drawing operations, or b=
atching groups of&nbsp;</div><div>operations in a composable way. It was an=
 abstract point more than a concrete proposal. This is simply one of those =
things that I=92ve talked</div><div>about at the beginning of the email: un=
discovered possibilities. Nobody has designed a drawing API that can levera=
ge lambdas because</div><div>C and C++ didn=92t have lambdas. Lambdas are o=
nly an example anyway, so don=92t ask me how they fit in the drawing librar=
y. I=92m only</div><div>saying I think it=92s worth spending some time inve=
stigating those possibilities to be able, maybe, to end up with something r=
eally innovative.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><br></div></div></blockquote><blockquote type=3D"cite=
"><div dir=3D"ltr"><div class=3D"gmail_extra">-Mike</div><div class=3D"gmai=
l_extra">&nbsp;</div></div></blockquote>Good bye,</div><div>Nicola</div><br=
></body></html>

<p></p>

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

--Apple-Mail=_6EDAB0A9-5180-4303-B71B-DC79D9D4ED52--

.

Il giorno 28/gen/2014, alle ore 17:58, Nicola Gigante <nicola.gigante@gmail.com> ha scritto:

>
>
> I'm afraid I've badly explained myself here. I know cairo has not been designed before. GDI was that "pre-C++98" library I was
> referring to, and I know it's not mentioned in your proposal. All I wanted to say was that "generally" I don't agree very much on the concept
> of taking a previous library and reshape it. I know, as you have said a few times, that this is only a starting point, don't worry about this.

Sorry, here I mean taking a previous _C_ library and reshape it... of course... reshaping previous libraries is what all the TR1 has done for C++11 :P

Nicola

--

---
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/.

.

On 2014-01-28 11:46, Thiago Macieira wrote:
> On ter=C3=A7a-feira, 28 de janeiro de 2014 09:44:08, Matthew Woehlke wrot=
e:
>> As I understood it, the point here is that the API should be agnostic to
>> the engine. Ideally to the extent that the engine can be changed without
>> recompiling code. This is the case with e.g. Qt, which allows swapping
>> out the underlying engine via an environment variable.
>>
>> Exposing too much of the underlying guts is an invitation to write
>> non-portable code.
>
> Which might be necessary. Not providing the native handles limits the
> usefulness to only the API that is provided, no extension possible.

Sure. I think what I'm trying to say is more that if the API is such=20
that writing native code is necessary more often than "rarely, and only=20
in special situations", it's not a very good API.

Also, I wouldn't write native access into the standard except perhaps=20
for some brief wording that implementations may extend the API for that=20
reason. Otherwise you *do* get into standardizing X / WinGDI / DirectX /=20
OpenGL / etc.

IOW let the platform vendor "standardize" native access, and only worry=20
about the homogenous API at the language level.

--=20
Matthew

--=20

---=20
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-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-proposa=
ls/.

.

On 28 January 2014 19:28, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> Also, I wouldn't write native access into the standard except perhaps for
> some brief wording that implementations may extend the API for that reason.
> Otherwise you *do* get into standardizing X / WinGDI / DirectX / OpenGL /
> etc.
>
> IOW let the platform vendor "standardize" native access, and only worry
> about the homogenous API at the language level.


I think it's beneficial to be able to do, in a fairly straightforward
manner, things like

auto h = foo.native_handle();
low_level_processing_func(h);
// or a combination as a single line

than having to write
#if defined(PLATFORM_X)
auto h = foo.get_native_handle_for_platform_x();
#elif defined(PLATFORM_Y)
yadda yadda yadda
#endif
low_level_processing_func(h); // I do hope that the #else branch
initialized a h...

--

---
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/.

.

On Tue, Jan 28, 2014 at 5:15 AM, Felipe Magno de Almeida
<felipe.m.almeida@gmail.com> wrote:
> On Tue, Jan 28, 2014 at 4:35 AM, Michael McLaughlin <mikebmcl@gmail.com> wrote:
>>
>
> [snip]
>
>>> rectangle and rectangle_int should be replaced with a template, instances
>>> of which are used in the api. This template along with point<T> should be in
>>> the top level std namespace and used throughout std when appropriate. Over
>>> time this will increase interoperability between 3rd party libraries as they
>>> start using them.
>>
>> I definitely agree as far as creating a point type. I need to think more
>> about the merits of templating point and rectangle; it seems obviously
>> good
>
> IMO the coordinate space should be parameterizable by algorithms, which
> makes rectangles and point obviously templates. But with the current OO
> API this doesn't make sense.

There might be use cases that need to parametrize the kind of integer
inside a point, but there also might not. We need concrete examples in
order to decide, not just a blind assumption that "real" C++ code
exposes templates instead of virtual functions or type erasure.

Jeffrey

--

---
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/.

.

On 2014-01-28 12:50, Ville Voutilainen wrote:
> On 28 January 2014 19:28, Matthew Woehlke
> <mw_triad@users.sourceforge.net> wrote:
>> Also, I wouldn't write native access into the standard except perhaps for
>> some brief wording that implementations may extend the API for that reason.
>> Otherwise you *do* get into standardizing X / WinGDI / DirectX / OpenGL /
>> etc.
>>
>> IOW let the platform vendor "standardize" native access, and only worry
>> about the homogenous API at the language level.
>
> I think it's beneficial to be able to do, in a fairly straightforward
> manner, things like
>
> auto h = foo.native_handle();
> low_level_processing_func(h);

As low_level_processing_func is presumably already conditionally defined
depending on the platform, why would you not simply pass 'foo' to it
directly? (What if different implementations have multiple possible
handles that the user may need? What if an implementation supports
multiple, runtime-selectable engines with different handle types?)

> #if defined(PLATFORM_X)
> auto h = foo.get_native_handle_for_platform_x();
> #elif defined(PLATFORM_Y)
> yadda yadda yadda
> #endif
> low_level_processing_func(h); // I do hope that the #else branch
> initialized a h...

If it didn't, would you not have also gotten a compile error in the
above version due to there being no appropriate overload (if there is a
definition at all) of low_level_processing_func?

--
Matthew

--

---
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/.

.

--089e013c6eea8bc47f04f10d87c3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 28, 2014 at 6:37 AM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.c=
om>wrote:

>
> On Tue, Jan 28, 2014 at 10:02 AM, Michael McLaughlin <mikebmcl@gmail.com>=
wrote:
>
>>
>> 12) Please investigate on an FP-like approach to compose drawing
>>> operations.
>>>   i.e. we have stroke() and fill(), make me compose them to stroke and
>>> fill and reuse the composition, in a way that it run faster than execut=
e
>>>  two operations again.
>>>
>>>
>> FP? I'm afraid I'm not sure what you are referring to. Possible because
>> it's 3:46 in the morning and all that is coming to mind is floating
>> point.
>>
>
> I believe FP here means Functional Programming (style).
>
> Thanks! That does indeed fit with the rest of the suggestion.

--=20

---=20
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-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-proposa=
ls/.

--089e013c6eea8bc47f04f10d87c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 28, 2014 at 6:37 AM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&l=
t;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
im"><br>
<div class=3D"gmail_quote">On Tue, Jan 28, 2014 at 10:02 AM, Michael McLaug=
hlin <span dir=3D"ltr">&lt;<a href=3D"mailto:mikebmcl@gmail.com" target=3D"=
_blank">mikebmcl@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,20=
4,204);border-left-width:1px;border-left-style:solid">


12) Please investigate on an FP-like approach to compose drawing operations=
..<br>
=C2=A0 i.e. we have stroke() and fill(), make me compose them to stroke and=
 fill and reuse the composition, in a way that it run faster than execute =
=C2=A0two operations again.<br>
<br></blockquote><div>=C2=A0</div></div><div>FP? I&#39;m afraid I&#39;m not=
 sure what you are referring to. Possible because it&#39;s <span><span>3:46=
</span></span> in the morning and all that is coming to mind is=C2=A0floati=
ng point.</div>

</blockquote></div><br></div>I believe FP here means Functional Programming=
 (style).</div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

</div></div></blockquote></div><font color=3D"#000000">Thanks! That does in=
deed fit with the rest of the suggestion. </font><br></div></div>

<p></p>

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

--089e013c6eea8bc47f04f10d87c3--

.

On 28 January 2014 20:49, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> On 2014-01-28 12:50, Ville Voutilainen wrote:
>> I think it's beneficial to be able to do, in a fairly straightforward
>> manner, things like
>> auto h = foo.native_handle();
>> low_level_processing_func(h);
> As low_level_processing_func is presumably already conditionally defined
> depending on the platform, why would you not simply pass 'foo' to it
> directly? (What if different implementations have multiple possible handles

Because I'd rather not duplicate the code that extracts the native handle
from foo.

> that the user may need? What if an implementation supports multiple,
> runtime-selectable engines with different handle types?)

Then these handles need to be separately extracted from the native handle.
That is, of course, not going to end up achieving the avoidance of boilerplate
in the previous part.

>> #if defined(PLATFORM_X)
>> auto h = foo.get_native_handle_for_platform_x();
>> #elif defined(PLATFORM_Y)
>> yadda yadda yadda
>> #endif
>> low_level_processing_func(h); // I do hope that the #else branch
>> initialized a h...
> If it didn't, would you not have also gotten a compile error in the above
> version due to there being no appropriate overload (if there is a definition
> at all) of low_level_processing_func?


Sure, but I would've gotten that compiler error from code that looks remotely
sane, rather than being a preprocessor mess.

--

---
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/.

.

--nextPart9006464.3KjmYKmPxi
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On ter=E7a-feira, 28 de janeiro de 2014 23:28:55, Ville Voutilainen wro=
te:
> > that the user may need? What if an implementation supports multiple=
,
> > runtime-selectable engines with different handle types?)
>=20
> Then these handles need to be separately extracted from the native ha=
ndle.
> That is, of course, not going to end up achieving the avoidance of
> boilerplate in the previous part.

FYI

This is exactly the case now in Qt 5 (especially on Unix), since the ba=
ckend=20
is selected at runtime and there are no macros you can #ifdef on.

There's a function that can return the name of the backend at runtime a=
nd you=20
have to make your decision then. That means the user application needs =
to=20
guess ahead of time which backends it might need to integrate. This is=20=

especially the case for Linux, where the backend might be "xcb", "wayla=
nd",=20
"eglfs" or other things.

The integration is done with a series of QPlatformXXXX classes, especia=
lly=20
QPlatformNativeInterface:

    virtual void *nativeResourceForIntegration(const QByteArray &resour=
ce);
    virtual void *nativeResourceForContext(const QByteArray &resource,=20=

QOpenGLContext *context);
    virtual void *nativeResourceForScreen(const QByteArray &resource, Q=
Screen=20
*screen);
    virtual void *nativeResourceForWindow(const QByteArray &resource, Q=
Window=20
*window);
    virtual void *nativeResourceForBackingStore(const QByteArray &resou=
rce,=20
QBackingStore *backingStore);

Used, for example, like:

// xcb:
xcb_connection_t *d =3D=20
=09qApp->nativeInterface()->nativeResourceForWindow("connection", w);

--=20
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

--nextPart9006464.3KjmYKmPxi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBS6CXlM/XwBW70U1gRAswiAJ9vbx7bI3wcYCgfpw/UHCw9tLAT1gCdH+a1
TYSWQhfTsZg/gOIKmWsrTU8=
=4o94
-----END PGP SIGNATURE-----

--nextPart9006464.3KjmYKmPxi--


.

------=_Part_4105_21131894.1391400860372
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

About method overloads that take point or rect types. I now came to the=20
conclusion that we should have a template overload to cater for "all" types
of point classes the user of the library may have on hand. Can this be=20
done? Yes: Using the same principles as std::begin() and std::end() it can,=
=20
even if x and y are not named so, for instance.

template <typename T> decltype(typename T::x) get_x(const T& src) { return=
=20
src.x; }

// But now, oops, MyPoint didn't have an x member as it has a double=20
data[2] instead to store the coordinates (it may be part of a matrix=20
library). This is easily fixed:

double get_x(const MyPoint& src) { return src.data[0]; }


// Functions taking points inside std::drawing classes then have this style=
=20
signature:

template<typename P> void DrawLine(const P& from, const P& to) {
    DrawLine(get_x(from), get_y(from), get_x(to), get_y(to));
}

// Which of course calls the non-template (virtual?) DrawLine() that does=
=20
the job.

// The get_x() returns decltype(T::x) to handle the possibility that there=
=20
are overloaded DrawLine for double and int parameters.

Aside: I think that the logical thing to do is to actually make such=20
methods virtual. Any drawing operation is going to be very heavy compared=
=20
to a virtual call. Forcing users to make templates out of all their drawing=
=20
code in order to draw on different devices is just not practical. Firstly=
=20
you don't want to have that type of code
in header files, and secondly you may not even know at the call site what=
=20
you are drawing on (for instance different types of printers or vector file=
=20
generators). Similar reasoning applies to image memory handling, where the=
=20
runtime file format of a loaded image file may cause different memory=20
layouts etc.

C++ provides many tools, we must try to use all of them appropriately!


Den tisdagen den 28:e januari 2014 kl. 22:49:19 UTC+1 skrev Thiago Macieira=
:
>
> On ter=C3=A7a-feira, 28 de janeiro de 2014 23:28:55, Ville Voutilainen wr=
ote:=20
> > > that the user may need? What if an implementation supports multiple,=
=20
> > > runtime-selectable engines with different handle types?)=20
> >=20
> > Then these handles need to be separately extracted from the native=20
> handle.=20
> > That is, of course, not going to end up achieving the avoidance of=20
> > boilerplate in the previous part.=20
>
> FYI=20
>
> This is exactly the case now in Qt 5 (especially on Unix), since the=20
> backend=20
> is selected at runtime and there are no macros you can #ifdef on.=20
>
> There's a function that can return the name of the backend at runtime and=
=20
> you=20
> have to make your decision then. That means the user application needs to=
=20
> guess ahead of time which backends it might need to integrate. This is=20
> especially the case for Linux, where the backend might be "xcb",=20
> "wayland",=20
> "eglfs" or other things.=20
>
> The integration is done with a series of QPlatformXXXX classes, especiall=
y=20
> QPlatformNativeInterface:=20
>
>     virtual void *nativeResourceForIntegration(const QByteArray=20
> &resource);=20
>     virtual void *nativeResourceForContext(const QByteArray &resource,=20
> QOpenGLContext *context);=20
>     virtual void *nativeResourceForScreen(const QByteArray &resource,=20
> QScreen=20
> *screen);=20
>     virtual void *nativeResourceForWindow(const QByteArray &resource,=20
> QWindow=20
> *window);=20
>     virtual void *nativeResourceForBackingStore(const QByteArray=20
> &resource,=20
> QBackingStore *backingStore);=20
>
> Used, for example, like:=20
>
> // xcb:=20
> xcb_connection_t *d =3D=20
>         qApp->nativeInterface()->nativeResourceForWindow("connection", w)=
;=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>

--=20

---=20
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-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-proposa=
ls/.

------=_Part_4105_21131894.1391400860372
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">About method overloads that take point or rect types. I no=
w came to the conclusion that we should have a template overload to cater f=
or "all" types<div>of point classes the user of the library may have on han=
d. Can this be done? Yes: Using the same principles as std::begin() and std=
::end() it can, even if x and y are not named so, for instance.</div><div><=
br></div><div>template &lt;typename T&gt;&nbsp;decltype(typename T::x)&nbsp=
;get_x(const T&amp; src) { return src.x; }</div><div><br></div><div>// But =
now, oops, MyPoint didn't have an x member as it has a double data[2] inste=
ad to store the coordinates (it may be part of a matrix library). This is e=
asily fixed:</div><div><br></div><div>double get_x(const MyPoint&amp; src) =
{ return src.data[0]; }</div><div><br></div><div><br></div><div>// Function=
s taking points inside std::drawing classes then have this style signature:=
</div><div><br></div><div>template&lt;typename P&gt; void DrawLine(const P&=
amp; from, const P&amp; to) {</div><div>&nbsp; &nbsp; DrawLine(get_x(from),=
 get_y(from), get_x(to), get_y(to));</div><div>}</div><div><br></div><div>/=
/ Which of course calls the non-template (virtual?) DrawLine() that does th=
e job.</div><div><br></div><div>// The get_x() returns decltype(T::x) to ha=
ndle the possibility that there are overloaded DrawLine for double and int =
parameters.</div><div><br></div><div>Aside: I think that the logical thing =
to do is to actually make such methods virtual. Any drawing operation is go=
ing to be very heavy compared to a virtual call. Forcing users to make temp=
lates out of all their drawing code in order to draw on different devices i=
s just not practical. Firstly you don't want to have that type of code</div=
><div>in header files, and secondly you may not even know at the call site =
what you are drawing on (for instance different types of printers or vector=
 file generators). Similar reasoning applies to image memory handling, wher=
e the runtime file format of a loaded image file may cause different memory=
 layouts etc.</div><div><br></div><div>C++ provides many tools, we must try=
 to use all of them appropriately!</div><div><br><br>Den tisdagen den 28:e =
januari 2014 kl. 22:49:19 UTC+1 skrev Thiago Macieira:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">On ter=C3=A7a-feira, 28 de janeiro de 2014 23:28:55=
, Ville Voutilainen wrote:
<br>&gt; &gt; that the user may need? What if an implementation supports mu=
ltiple,
<br>&gt; &gt; runtime-selectable engines with different handle types?)
<br>&gt;=20
<br>&gt; Then these handles need to be separately extracted from the native=
 handle.
<br>&gt; That is, of course, not going to end up achieving the avoidance of
<br>&gt; boilerplate in the previous part.
<br>
<br>FYI
<br>
<br>This is exactly the case now in Qt 5 (especially on Unix), since the ba=
ckend=20
<br>is selected at runtime and there are no macros you can #ifdef on.
<br>
<br>There's a function that can return the name of the backend at runtime a=
nd you=20
<br>have to make your decision then. That means the user application needs =
to=20
<br>guess ahead of time which backends it might need to integrate. This is=
=20
<br>especially the case for Linux, where the backend might be "xcb", "wayla=
nd",=20
<br>"eglfs" or other things.
<br>
<br>The integration is done with a series of QPlatformXXXX classes, especia=
lly=20
<br>QPlatformNativeInterface:
<br>
<br>&nbsp; &nbsp; virtual void *nativeResourceForIntegration(<wbr>const QBy=
teArray &amp;resource);
<br>&nbsp; &nbsp; virtual void *nativeResourceForContext(<wbr>const QByteAr=
ray &amp;resource,=20
<br>QOpenGLContext *context);
<br>&nbsp; &nbsp; virtual void *nativeResourceForScreen(const QByteArray &a=
mp;resource, QScreen=20
<br>*screen);
<br>&nbsp; &nbsp; virtual void *nativeResourceForWindow(const QByteArray &a=
mp;resource, QWindow=20
<br>*window);
<br>&nbsp; &nbsp; virtual void *<wbr>nativeResourceForBackingStore(<wbr>con=
st QByteArray &amp;resource,=20
<br>QBackingStore *backingStore);
<br>
<br>Used, for example, like:
<br>
<br>// xcb:
<br>xcb_connection_t *d =3D=20
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;qApp-&gt;nativeInterfac=
e(<wbr>)-&gt;nativeResourceForWindow("<wbr>connection", w);
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br></blockquote></div></div>

<p></p>

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

------=_Part_4105_21131894.1391400860372--

.

Em dom 02 fev 2014, =E0s 20:14:20, Bengt Gustafsson escreveu:
> About method overloads that take point or rect types. I now came to the
> conclusion that we should have a template overload to cater for "all" typ=
es
> of point classes the user of the library may have on hand. Can this be
> done? Yes:=20

Should it be done? IMHO, no.

Making an entirely-template API means potentially a lot of code bloat. It=
=20
means all of the actual API is implemented in private APIs, called by inlin=
e=20
template methods.

> C++ provides many tools, we must try to use all of them appropriately!

Appropriately also implies that there are conditions under which some tools=
=20
must not be used. I believe this to be one of them.

--=20
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

--=20

---=20
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-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-proposa=
ls/.

.

------=_Part_2661_7413169.1391987538228
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The compiler will definitely inline those trivial adaptor methods which=20
look like this or very similar:

getx(const my_point& p) { return p.x; }

It won't generate any object code bloat at all. The alternative, using a=20
std::drawing specific point class will however require creating a temprary=
=20
object which in some cases is harder to optimize away, and introduces a lot=
=20
of SOURCE code bloat:

dc.draw_point(std::drawing::point(p.x, p.y));

instead of:

dc.draw_point(p);

I think this is quite compelling!

By the way: Drawing methods such as draw_polygon which take a range of=20
points can also be written to accept diffrerent types of points, although=
=20
it will be harder to optimize away copying of data, depending on the=20
underlying "device driver" implementation.


Den m=C3=A5ndagen den 3:e februari 2014 kl. 05:54:32 UTC+1 skrev Thiago Mac=
ieira:
>
> Em dom 02 fev 2014, =C3=A0s 20:14:20, Bengt Gustafsson escreveu:=20
> > About method overloads that take point or rect types. I now came to the=
=20
> > conclusion that we should have a template overload to cater for "all"=
=20
> types=20
> > of point classes the user of the library may have on hand. Can this be=
=20
> > done? Yes:=20
>
> Should it be done? IMHO, no.=20
>
> Making an entirely-template API means potentially a lot of code bloat. It=
=20
> means all of the actual API is implemented in private APIs, called by=20
> inline=20
> template methods.=20
>
> > C++ provides many tools, we must try to use all of them appropriately!=
=20
>
> Appropriately also implies that there are conditions under which some=20
> tools=20
> must not be used. I believe this to be one of them.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
>

--=20

---=20
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-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-proposa=
ls/.

------=_Part_2661_7413169.1391987538228
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The compiler will definitely inline those trivial adaptor =
methods which look like this or very similar:<div><br></div><div>getx(const=
 my_point&amp; p) { return p.x; }</div><div><br></div><div>It won't generat=
e any object code bloat at all. The alternative, using a std::drawing speci=
fic point class will however require creating a temprary object which in so=
me cases is harder to optimize away, and introduces a lot of SOURCE code bl=
oat:</div><div><br></div><div>dc.draw_point(std::drawing::point(p.x, p.y));=
</div><div><br></div><div>instead of:</div><div><br></div><div>dc.draw_poin=
t(p);</div><div><br></div><div>I think this is quite compelling!</div><div>=
<br></div><div>By the way: Drawing methods such as draw_polygon which take =
a range of points can also be written to accept diffrerent types of points,=
 although it will be harder to optimize away copying of data, depending on =
the underlying "device driver" implementation.</div><div><br></div><div><br=
><div>Den m=C3=A5ndagen den 3:e februari 2014 kl. 05:54:32 UTC+1 skrev Thia=
go Macieira:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em dom 02 fev 2014=
, =C3=A0s 20:14:20, Bengt Gustafsson escreveu:
<br>&gt; About method overloads that take point or rect types. I now came t=
o the
<br>&gt; conclusion that we should have a template overload to cater for "a=
ll" types
<br>&gt; of point classes the user of the library may have on hand. Can thi=
s be
<br>&gt; done? Yes:=20
<br>
<br>Should it be done? IMHO, no.
<br>
<br>Making an entirely-template API means potentially a lot of code bloat. =
It=20
<br>means all of the actual API is implemented in private APIs, called by i=
nline=20
<br>template methods.
<br>
<br>&gt; C++ provides many tools, we must try to use all of them appropriat=
ely!
<br>
<br>Appropriately also implies that there are conditions under which some t=
ools=20
<br>must not be used. I believe this to be one of them.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div></div></div>

<p></p>

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

------=_Part_2661_7413169.1391987538228--

.

Em dom 09 fev 2014, =E0s 15:12:18, Bengt Gustafsson escreveu:
> It won't generate any object code bloat at all. The alternative, using a=
=20
> std::drawing specific point class will however require creating a temprar=
y=20
> object which in some cases is harder to optimize away, and introduces a l=
ot=20
> of SOURCE code bloat:
>=20
> dc.draw_point(std::drawing::point(p.x, p.y));

It only  happens if you have a foreign point type in the first place. I'm=
=20
recommending you don't. Stick to what the framework gives you.
--=20
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

--=20

---=20
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-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-proposa=
ls/.

.

------=_Part_851_14844347.1392071908593
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We can dream of being able to do that. I have worked in image processing=20
and graphics for 20 years in C++ now, and I can assure you that there are a=
=20
gazillion of point struct out there that are not going away anytime soon.=
=20
90% or more have x and y members which are ints or doubles...

This of course was caused by C++ not defining a point struct in the=20
standard initially, forcing everyone to invent one of their own. Now with=
=20
new features and techniques we are in the position to be able to create a=
=20
decent level of interoperability
despite this oversight. I suggest we use it or a standard drawing API will=
=20
be still born.

Den m=C3=A5ndagen den 10:e februari 2014 kl. 06:22:22 UTC+1 skrev Thiago=20
Macieira:
>
> Em dom 09 fev 2014, =C3=A0s 15:12:18, Bengt Gustafsson escreveu:=20
> > It won't generate any object code bloat at all. The alternative, using =
a=20
> > std::drawing specific point class will however require creating a=20
> temprary=20
> > object which in some cases is harder to optimize away, and introduces a=
=20
> lot=20
> > of SOURCE code bloat:=20
> >=20
> > dc.draw_point(std::drawing::point(p.x, p.y));=20
>
> It only  happens if you have a foreign point type in the first place. I'm=
=20
> recommending you don't. Stick to what the framework gives you.=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
>

--=20

---=20
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-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-proposa=
ls/.

------=_Part_851_14844347.1392071908593
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We can dream of being able to do that. I have worked in im=
age processing and graphics for 20 years in C++ now, and I can assure you t=
hat there are a gazillion of point struct out there that are not going away=
 anytime soon. 90% or more have x and y members which are ints or doubles..=
..<div><br></div><div>This of course was caused by C++ not defining a point =
struct in the standard initially, forcing everyone to invent one of their o=
wn. Now with new features and techniques we are in the position to be able =
to create a decent level of interoperability</div><div>despite this oversig=
ht.<span style=3D"font-size: 13px;">&nbsp;I suggest we use it or a standard=
 drawing API will be still born.</span></div><div><br>Den m=C3=A5ndagen den=
 10:e februari 2014 kl. 06:22:22 UTC+1 skrev Thiago Macieira:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">Em dom 09 fev 2014, =C3=A0s 15:12:18, Bengt =
Gustafsson escreveu:
<br>&gt; It won't generate any object code bloat at all. The alternative, u=
sing a=20
<br>&gt; std::drawing specific point class will however require creating a =
temprary=20
<br>&gt; object which in some cases is harder to optimize away, and introdu=
ces a lot=20
<br>&gt; of SOURCE code bloat:
<br>&gt;=20
<br>&gt; dc.draw_point(std::drawing::<wbr>point(p.x, p.y));
<br>
<br>It only &nbsp;happens if you have a foreign point type in the first pla=
ce. I'm=20
<br>recommending you don't. Stick to what the framework gives you.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div></div>

<p></p>

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

------=_Part_851_14844347.1392071908593--

.

------=_Part_247_701403206.1424168206568
Content-Type: multipart/alternative;
 boundary="----=_Part_248_945944859.1424168206568"

------=_Part_248_945944859.1424168206568
Content-Type: text/plain; charset=UTF-8

I'm so sorry, but i don't understand, why point has all kinds of operations?
in a normal mode i can't add smth to point, the code
point a = {1, 1}, b = {1, 2};
a += b;

is without any sense.

--

---
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_248_945944859.1424168206568
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'm so sorry, but i don't understand, why point has all ki=
nds of operations?<div>in a normal mode i can't add smth to point, the code=
</div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 1=
87); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">point a </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">},</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> b </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-pre=
ttify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>a </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">+=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span></div></code></div><div><br></div><div>is with=
out any sense.<br></div></div>

<p></p>

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

------=_Part_248_945944859.1424168206568--
------=_Part_247_701403206.1424168206568--

.