220 8884 article Path: news.gmane.org!not-for-mail From: Michael McLaughlin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Comments on 2d api for c++ N3888.pdf Date: Tue, 28 Jan 2014 01:35:05 -0500 Lines: 1202 Approved: news@gmane.org Message-ID: References: <9105f9b2-e15d-4bf8-a4a1-65ebc3657eb0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b5d3b6e5b9e1304f1020632 X-Trace: ger.gmane.org 1390890901 28863 80.91.229.3 (28 Jan 2014 06:35:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jan 2014 06:35:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCX3XKVL7MKRBHE7TWLQKGQEGPPJTSY@isocpp.org Tue Jan 28 07:35:09 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-bk0-f70.google.com ([209.85.214.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W82GL-0006H2-EH for gclcip-std-proposals@m.gmane.org; Tue, 28 Jan 2014 07:35:09 +0100 Original-Received: by mail-bk0-f70.google.com with SMTP id na10sf685764bkb.5 for ; Mon, 27 Jan 2014 22:35:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=M+jU0yEgzM+/YMRnHWmAjsPwcFduRpSMKpvx/AoxTZ4=; b=V/SUGA3inPCsUmr8EeE3l1FZ55sg82N42d81zk6LuQiLRV1LHGIj0Eoo4R6hlbEqzW IgVUrBw70TM/4LV3k0pxmsFKiC9p82MYQwlh5FIiQKIReMBGjRPuPkWn884JRlVr++u6 f6hoSMJDl1lGKtBQo8wr7jDoJeKo7HKH8TFXJ7+CQl56cfNDftPfMr+om8u6eBvico+O qMqDqgONAtCkuyRPvVu82uCYRbSghiUuHuypaxkoyhDdIbSxMMC5Uw9OMHeMGWSZmxat GVJXfql2TBwE62rU3MVr9Mg8KEOe0LB27wuz8ixmmnpeL7Rn344ZVQTcxol/ED6jRNMl TfrQ== X-Gm-Message-State: ALoCoQn5l3FOl7zS6kCgKAw+zfpICeVnsrszpU39Q4U3IXEMnbNLfCQvMyDKeJgBmZzXDNl6HV5t X-Received: by 10.180.92.226 with SMTP id cp2mr14245879wib.6.1390890908825; Mon, 27 Jan 2014 22:35:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.19.202 with SMTP id h10ls429259wie.41.gmail; Mon, 27 Jan 2014 22:35:07 -0800 (PST) X-Received: by 10.204.71.5 with SMTP id f5mr916537bkj.25.1390890907570; Mon, 27 Jan 2014 22:35:07 -0800 (PST) Original-Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [2607:f8b0:4001:c03::22b]) by mx.google.com with ESMTPS id w6si16755417bkh.148.2014.01.27.22.35.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 22:35:07 -0800 (PST) Received-SPF: pass (google.com: domain of mikebmcl@gmail.com designates 2607:f8b0:4001:c03::22b as permitted sender) client-ip=2607:f8b0:4001:c03::22b; Original-Received: by mail-ie0-f171.google.com with SMTP id as1so7173934iec.2 for ; Mon, 27 Jan 2014 22:35:05 -0800 (PST) X-Received: by 10.43.78.78 with SMTP id zl14mr25262127icb.5.1390890905737; Mon, 27 Jan 2014 22:35:05 -0800 (PST) Original-Received: by 10.64.14.97 with HTTP; Mon, 27 Jan 2014 22:35:05 -0800 (PST) In-Reply-To: X-Original-Sender: mikebmcl@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mikebmcl@gmail.com designates 2607:f8b0:4001:c03::22b as permitted sender) smtp.mail=mikebmcl@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8884 Archived-At: --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 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 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 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 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 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
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 stan= dardized 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 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.

=C2=A0
First, thank you for th= e detailed, insightful feedback! I appreciate it very much.
=C2= =A0
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).
=C2=A0
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'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.
=C2=A0

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:

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
subpixel_order information.

=C2=A0
Right now the semantics of the library are a= s defined in the cairo API documentation:=C2=A0http://cairographics.org/manual/ . T= he subpixel order details=C2=A0are described there and are defined in a way= that they are reliant on the machine endianness.
=C2=A0
We've decided to handle proposed changes by makin= g them issues tagged=C2=A0with "enhancement" in the GitHub reposi= tory for the reference implementation: https://github.com/= mikebmcl/N3888_RefImpl/issues?state=3Dopen . 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'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.
=C2=A0
I'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: https://github.com/mikebmcl/N3888_RefImpl/issues/12 . = If you prefer just=C2=A0to post it here instead then I will take=C2=A0care = of adding it there.
=C2=A0
I generally agree about adding more formats.=C2=A0I a= dded some thoughts I have on practical implications we'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'll need to decide how to ha= ndle unsupported formats, and that it'd also be good to consider what, = if any, mandatory formats there should be).
=C2=A0
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't for some reason.
=C2=A0
=C2=A0
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?
=C2=A0
I'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'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.
=C2=A0
I think that in general we can go a bit above the lea= st common denominator (especially=C2=A0where there's a reasonable fallb= ack for platforms that don't support a particular feature). But I'd= rather be in the position of receiving requests for more features than com= plaints that implementations aren't delivering what the interface appea= rs, at a casual glance,=C2=A0to offer.
=C2=A0
My view here is to defer consideration of this until = later in the process.
=C2=A0


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

=C2=A0
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= 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'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.
=C2=A0
So I'm adding a suggestion to create these class = template types but I'm not adding in a suggestion to=C2=A0move them to = std. That'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't yet been published (even if it has, we c= ould still probably work something out, though it'd be harder).
=C2=A0

Similarly matrix should be called something like transform_matrix and = inherit a generic std::matrix<2,3>, adding the affine transform speci= fic setup methods as indicated.
=C2=A0
I think this is a good idea,=C2=A0but I'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'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 "question" issue as a remin= der 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.
=C2=A0
Regardless, until we check with SG6 and hear back fro= m 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 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.
=C2=A0
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.
=C2=A0


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

= =C2=A0
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.<= /div>
=C2=A0

Is user_data_key and its use in device/surface really necessary to hav= e?

=C2=A0
As far as I'm concerned, user_data_key (and the functionality it exist= s to provide) should be obliterated. It's already a suggestion. But it&= #39;s nice to know that others also question its usefulness.
=C2=A0

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.

=C2=A0
I hones= tly don't know if there'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's there because it came along a= s part of the mechanical transformation.
=C2=A0
=C2=A0
=
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 "handles" 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).

=C2=A0
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'll be in Issaquah, part of the presentation I= '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'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).
=C2=A0
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.
=C2=A0

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

=C2=A0
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't see any reason to keep thi= s as a double (what it is currently). That said, I'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'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'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.
=C2=A0
=C2=A0
=
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.

=C2=A0
This isn't the only place where this= "out" 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's in the queue now so that when the time is right it will be deal= t with.
=C2=A0

It seems that the fallback resolution handling would be more appropria= tely placed in device.

mark_dirty_rectange shoud b= e available with a rectangle<int> as parameter. It seems inconsistent= that the subsurface creation ctor takes a double rect and the dirty functi= on 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.

=C2=A0
The fallback resolution=C2=A0functionali= ty 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=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'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'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'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'll eliminate it in a later pass.
=C2=A0

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 "make file formats equal" 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).

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.

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

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

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.
=C2=A0
It comes from cairo= 9;s PNG functionality. I'm in favor of extending it to more image types= rather than eliminating it.
=C2=A0
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.
=C2=A0
There'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't have data to put in it right away, yo= u can still call reserve on it. You'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.
=C2=A0
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.
=C2=A0
Yeah, it's PNG again (the filename c= tor). I have an email from the cairo mailing list to do something about thi= s 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 imag= e 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 t= o reuse them in future extensions working with colors in other ways.
=C2=A0
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'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.
=C2=A0
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 kno= w what values to use to get cornflower blue or any number of other named co= lors that I'm used to having available). And it may be that one will pr= ove both useful and feasible here. But it's non-trivial and it's no= t 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 i= t must exist now because otherwise the chair may decide not to=C2=A0enterta= in it).
=C2=A0


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's at least not have more than one type r= epresenting a in-memory stored x,y indexed raster of pixels!
=C2=A0
I'm not going to a= dd 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. 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'm familiar = with. Just because all data is bytes doesn't mean we should abandon goo= d conceptual frameworks to in order to generalize concepts.
=C2=A0


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.

=C2=A0
The ter= m texture isn't used anywhere in the drawing header. I'm not quite = sure what you're talking about here. Perhaps I'm misunderstanding y= ou?
=C2=A0
=C2=A0
=
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" or "raster" 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's selection of file.

The raster_source_pattern has a lot of callbacks and vo= id* closure data that needs to be cleared out.
=C2=A0
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'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.
=C2=A0


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

=C2=A0
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.
=C2=A0
=C2=A0
=
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't even think it really=C2=A0is=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't how= ever think that this is the intention of this proposal, is it?

=C2=A0
As expl= ained=C2=A0at the beginning of this reply, cairo's origins are in X11 a= nd Win32 wasn'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.
=C2=A0

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 "sourc _pattern" of a context and = then drawing a filled rectangle(!) to actually get the image data drawn.

=C2=A0
Me too.= =C2=A0This can easily be added later since it is already=C2=A0possible=C2= =A0now.=C2=A0It's not central to evaluating N3888 as a starting point s= o I'm not filing an issue for it.
=C2=A0

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.

=C2=A0
The API as it stands deals in UTF-8 only. I'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's not going int= o this proposal or anything based on it. Sorry.
=C2=A0
=C2=A0
=
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 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.

Polyline/polygon drawing should be included, using a ra= nge-of-pointers concept.

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 "empty" 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" or something like this.

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?

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.

=C2=A0
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.
=C2=A0
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't things I'm inclined to add to the (ever increasing) issu= es list since they can be done later once we've decided on whether N388= 8 or N3888 with modifications will be a suitable starting point for the lib= rary.
=C2=A0
Thank you again for taking the time to make all these= recommendations!
=C2=A0
-Mike

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