Date: Tue, 23 Jul 2019 19:54:23 +0000
Hello all,
I attach below draft public minutes of the discussion on Thursday in Cologne (derived from the WG21 minutes on the SG13 Wiki.)
I attach below draft public minutes of the discussion on Thursday in Cologne (derived from the WG21 minutes on the SG13 Wiki.)
-- ---+++ SG13 After Lunch There were 18 attendees present We began with a discussion of P1108R2: web_view ---++++ Discussion (Presenting) This is an updated paper since reviewing in LEWGI (R3 to come in post-meeting mailing) There are multiple IO proposals, this is a proposal that tries to �bite off all of the enchilada all at once� It is complimentary to the group level up approaches, and there is a lot of value in those proposals We need to think really hard about user interaction, especially on modern devices � desktop & mobile Also need to support auxillary technologogies, not just rendering text but also things like screen readers, accessibility, audio, video, etc The question is: How should a modern C++ application interact with this huge ecosystem? I think the answer should be to outsource as much as possible to other existing groups that already have existing solutions (HTML, Javascript, etc) The benefit of the proposal being short � Web technologies are complicated; there are many implementations: WebKit, Gecko, Microsofts implementation and Chromium Links in the paper to the different APIs Web is a complicated space; you need the ability to display some window and then ask the system to display some content I think the important thing here is is that you have to think about this as a system service There is not a standardized interface yet, but there is a common set across these APIs I do want to mention quickly � people have asked � how does this compare to standardize a native API that these technologies covers? If you look at Qt, they have ~1600 classes and ~13000 functions, it is not easy QML/QtQuick is another alternative but 3 thoughts on this: 1. There is 1 version for mobile 1 for desktop Q: QML is a completely different level of abstraction; we are talking more low level than that A: I am attempting to motivate why we are at such a high level There were very serious suggestions saying we should take one of the existing codebases / technologes and use this as starting point. However, as ISO we can�t really just point at Qt and say do what they do This would inevitably leave to a ton of arguments Q: Should be sent to SG16 for Unicode reviewing Commenting on the long list of standards: Legislating this list should be under SG13�s perview; and I think this is a bad idea These standards don�t evolve together; you should just pop a web_view to whatever you want You are effectively saying I need to go to the vendor Reply: I went to caniuse.com, and this is where this list came from Comments: We can�t surface all of this stuff, such as geolocation � this requires user consent; there is a ton of complexity in this stuff You are also legislating legacy technology to be maintained I agree that this should become a quality of implementation in terms of what you support, however, I would like to see if there is a bare minimum Comment: Graphics, audio at some point to be supported; native approaches / techniques might be procluded by your approach Is this designed to be a closed list? A: No, I am not proposing this to cut off certain technologies Everyone knows what this list does Q: Do you know what that is? I don�t. And how would you standardise this? Some of this stuff v few ppl understand b/c it is too new or now enough implementations So we seem to be recommending standardizing existing practice QtWebView / MacOS WebKit do something similar to this Q: My question is there any examples similar to what we are trying to do here? A: Not to my knowledge Sciter, they have HTML5 and CSS and you can do C++ applications with this; this 5 MB; it is propietary; UltraLight is another example of something similar ( back to demoing the interface / use case of the interface - 1st example - �Time has passed� demo) There is a custom URI scheme registered WxWidgets provides this ability which Qt does not The stuff happening on screen is not being run by Javascript, it is being injected by the C++ code Q: How does this work? I will show you ( back to code behind demo ) Q: This is pretty worrying as an API. One of the most common uses of webview is a payment page. The problem is that the application does not own the payment part. There are native ways to do payments, lets ignore that You the app, aren't the same owner as the page you have opened This allows you open a webpage and then inject code into a �page� that you do not own A: Yes I saw a way to do that with the frameworks, which probably creates a problems There are ways to do this, i.e. HTTPRequest, and then the webpage can (localhost) agree to let this work Good thing to note Q: Depending on how the app is setup and presents it self as a browser wrapper vs an engine on the platform are two different cases. *Summary:* Javascript pages with injection into pages it does not own has security implications. Q: Is there any kind of synchronization with script on the page vs navigating to another page When you ask it to display this URI, you do have to wait until the page is done Q: I am in a while loop, window wasnt closed, I come to run script � I attempt to run it. How can I be certain I have the correct page? This is a good point. Q: Looks like you used a custom URI Scheme. Can you explain that? The scheme only works within the app. Q: OK. What happens if you do display from URI back to back from multiple things? Webview maps to one logical window. Q: And you can create multiple webviews? Yes. The way I envision this working, if there are system limitations preventing this, the api returns error codes so it could fail Q: On the scheme handler, this acts synchonously, if I want to do blocking calls � is there a design choice for not returning a future or suspending this? Or even forwarding to an existing handler to do some wrapping or something like that? If you want to get a request, and cause the whole page to navigate somewhere else, you would return false and then call a displacement URI I don�t have anyway providing a wrapper of an HTTP implementation-defined Note that there is not parameter that gives you any auxilary data here. Comment: When you register a URI scheme handler, aka I pop open www.google.com � and then the URI scheme can use that I think so *Summary:* Can the webpage make requests to that URI Scheme? The answer is yes. Comment: I was worried about was how to C++ talk to the webpage, and vice versa. This addresses that. ( back to demoing code ) Notes that due to asychronous nature this needs to go through SG1 Q: What does irrevocably unusable? That was my best guess at how to word a window closing Q: Just concerned about translating to starndardese It is supposed to mean the user cannot get to it anymore, it was my best guess at it � but I am hapy to take suggestions on that I have a second demo Using SlickGrid and UIKit to look really nice The app is very similar to the other one Q: So the slider is C++ injected? No, but the data in the table is So that is the interface � I think this is a nice area for standardization It lets user take advantage of the vibrant ecosystem, write modern C++ looking apps and it allows us to reference existing standards that takes advantages of existing technologies for rendering, etc. Q: Is there a link to a github where I can play with this? A: It is hidden in a paragraph. WebView link right after the code. Or: [[ https://github.com/hfinkel/web_view ]] Comment: my company supports this proposal and if SG13 is going to prioritize a graphics proposal, this is the one we think that should be prioritized There are issues around asynchronous behaviour (i.e. win32). The way callbacks are handled, there is more play there. The way the underlying implementations work, there could be nice solutions here. Q: Have you considering an interface that exposes that underlying implementation? You can provide native handles sometimes. Native handle to what? In this case, I could imagine a native handle to the window, etc. Comment: Generally, create a struct that contains all the handles in one place. Comment: On the scheme handler, we definitely want to be able fetch thing over the network. We need some form of asychronisty � but not necessarily going to the underlying implemetation. SG1 will be could to get feedback on executors interop Comment: Or coroutines We need to figure out on all systems that are relevant, if it is more reasonable for allowing the handler to block and allow multiple vs not blocking and having more aschronousity. Comment: I also agree that native handle is important, you might be overthinking it � but really all you need is an entry point. The frame would probably suffice. When ppl proposed adding native handles, comments were made if there always was a unique native handle � but yes we want to do the thing that is most useful Q: Would this run full screen? Great question. Right now, the prototype runs full screen (or techincally maximized). On some platforms not such thing as not full screen. You might want to do something like set a minimum size. Are you worried about being too big? Too small? Whats the concern? Comment: Flexibilty Q: You have run_script? An evolution of that is loading and parsing being split. I could provide that interface, but it probably doesnt change much. Comment: But it is still a nicer implementation. I see this as the main interaction with C++ with the web part Q: Have you thought about make the interface more sophisticated in terms of types? Q: More type safety Imagine a future where WASM (Web Assembly) is ubiquitous, supporting multiple types of scripts � if you had some type of WASM blob to run, do we need another interface? Comment: First we need UFT-16. But ignore. WASM is 87% supported by devices. WASM is neither Web, nor assembly. Is very similar to ELF-binary in terms of idea. It would be perfectly reasonable to have an API that supports something other than Javascript Chair: 3:00 PM, would like to wrap up this discussion soon. Comment: You define concepts, never use Comment: The name is a bit confusing, web_view � similar to string_view Comment: This is a term of art, lets leave it to LEWGI Q: Are any other polls requested? Q: Are other graphics/audio initiatives subsumed by this? Q: If you open this screen, is there some way to solve this using buffers? Comment: Bank website � I don�t want someone screenshotting my website Comment: We aren't building sandbox __POLL: We encourage further work on this paper.__ |SF|F|N|A|SA| |3|7|5|0|0| __POLL: P1108 should co-exist with SG13 graphics proposals__ |SF|F|N|A|SA| |7|3|5|0|0| __POLL: P1108 should co-exist with SG13 audio proposals__ |SF|F|N|A|SA| |8|4|3|0|0| ---+ P0267R9: A Proposal to Add 2D Graphics Rendering and Display to C++ ---++++ Discussion Background Is a paper in response to request for graphics support, SG13 was convened, paper is on r9 (12th or 13th revision though), very mature paper. Essentially, it is a drawing API. Not trying to emulate GPU programming, just trying to plot, draw text. Not a UI toolkit. Q: So this is similar to Turbo Pascal? Access to pixels on the screen Do not have access to pixels on the screen � A front end, what you would expect, all the standard operations since PostScript. Backend requirements are stated and anyone can implement them for whatever platforms they please Backend changes were added in r8. You could imagine Qt will have different backend from Microsoft. Provides 5 fundamental output ops: paint, stroke, fill, mask, drawtext. Drawtext is a bit more complicated. Guidance for reading P0267r9: section 2.a.i text metrics: right now we don�t have a way to do, this is what this section is for section 2.b command lists: these enables a set of commands to perform the 5 fundamental output ops Q: Are there examples? I wrote Asteroids Yes https://github.com/cpp-io2d there is a full implementation here That is the one that currently has text � pulls in Pango which is commonly used with Cairo that uses text. So the main two additions in r9: text rendering and command lists Reviewed by LWG at least 5 times, favorably Rapperwil LWG evening session killed this proposal with P1200. Text rendering has been added, now will go to LEWG and ultimately go to a TS Q: Havent read r9, read r8 extensively, P1225 was created as a minimal subset of what would be needed to approve, can you speak to which of these have been addressed by r9? Specifically a point by point response to what is listed in Section 2, 4 and 5. Q: P1062 � similar, but different, list. --- Summary of command lists. Provides callbacks to the 5 fundamental output ops. Giving a summary / walking through details of command list (starting page 202 of P0267r9) There are some unique use cases for �optional surface� where it is very useful (Reviewing page 223) run_function Q: You provide a command list, and one of the components can be a runfunc? Yes Q: More than one? Yes, as many as you want. Could be modified to the last new changed command list. Q: Can we see examples on how to use this? To solve any example problems There is at least one sample, where command lists are in the implementation Q: Is this in the paper? Or Github Github https://github.com/cpp-io2d (Currently on the r9 branch - it will be merged soon) It is in the draw Samples/draw_cpp/main.cpp Q: push_back of clear - why is it named clear? In the scope of command list, I would think it clears commands. It is named clear but it is the name of one of the methods Is is confusing because of the ambiguity I will rename this to something like clear_surface() I will take this as an action item That will go into r10 now review the main.cpp file The implementation is not required to deal with any race conditions Q: Is there specification on which thread it runs on? Or is that up to the backend? Dealing with locks/mutexes, Q: Do we have another place in the standard where we could have locks/mutexes? I am more concerned when it says is may create a thread, vs it will create a thread. I am am bound by what is in the standard Comment: Async is a very bad example I propose we talk about threading We should wait until direction from SG1 This is a SG1 specific thing, and SG13 should wait Comment: We can only use what is in C++17 right now. It can refer to any paper published and be developed on top of that Feedback from SG16, why not u8string instead of std::string � and it will as soon as it is in the standard Q: I have a question on the overall concept on how to design this: the fundamental idea is that you take a concept of a 2d surface on which you can execute drawing primitive. The set of ops is unlimited on a surface if you can build new surface. How has the design arrived at point � *Question summary:* Why a closed set of member operations as opposed a open set of non-member operations (i.e. similar to <algorithm> algorithms) This design doesn�t work with an because the back-end operations wouldn�t be known, and the back-end needs to know in order to implement them. Q: These are the 5 for the next 20 years? A while ago, things were very stateful which let you have much more freedom. Q: Has this been implemented with graphics that uses hardware acceleration? No, but I looked at DirectX to see if this would be successful, and in the process TS we will get feedback on that. Q: I am trying to understand how invoking arbitrary functions would work in the middle of some serial operations. The back-end would process things that need to be serial � Q: If you had a command list: draw, draw, draw, draw � you would end up doing 3 batches of operations Yes, that would be the way Q: The basic commands take a graphics surface template argument Is there any runtime polymorphic way to access ? The backend defines certain named types, if you are working with a backend that you know, you can operate on this similar to a native handle � you could go in but you would have to manage your code Q: On the basic commands, we have this class template that provides command like clear, fill, etc. Why are they different per surface? They depend on the template parameters That parameter is the back-end Q: That command needs to be there for all surfaces Yes Q: Why are the methods dependent on the graphic surfaces Graphics surfaces are the back end Q: Why is basic commands a templates When you create a command list of these things, they all store the same information, It doesn�t seem clear to me why the class layout depends of that information Each command is taking in state objects � yes we could create a list of data at the front end but the back end needs to do a bunch of process Forcing a defined front-end avoids this backend processing Comment: But I could choose to work on the backend specific part Q: My question was: can I do this or not? You can only run operations on the backend that are a part of that backend Those commands are on the backend so that Comment: Just to state it loudly, the consequence of this design � you can never plugin a backend at runtime. Comment: As an author, I want to ship a binary that can work with many backends This design forces me to be dependent on the backends Comment: If we have a polymorphic design, we can never never change those base class designs. Your backend doesnt need to only one technology. The backend could have fallbacks if something doesnt work, but that is up to the implementer of the backend. If the acceleration abilities don�t happen � I believe you would lose a lot of the optimization Comment: You can still allow that, and provide a runtime polymorphism interface as well If prevents you from doing compile-time optimization Comment: What I understand you can do � you can�t really do without the backend In theory, you could do it without the backend being involed. But then all the states classes but be defined and the front end and then kicked to the backend. And that will take up memory, processing time in both the front end and back end Comment: If your backend has the same interface of the presumed back ened, you could have back end compile switch to help The idea of a backend template evolved from LEWG drove this design Q: Would I ever need to use two backend within 1 program? libc++ and libstdc++ is designed to support multiple backends, there is no use case for using two different backends within the same program. I would imagine we could do the same thing here Comment: If I wanted to write to an offscreen image, would I want to use the same backend Fair point Comment: Not sure we want to support that, but it is an example If you use a different backend for write to file and writing to screen, so I dont why � unless you need to write a file Just to kind of cut this off, I think it would be better if someone wrote a paper with what someone would want to see. Q: Part of my confusion is what is backend? basic_image_surface Comment: Than I get even more command list types >From your persepective, it doesnt matter what back end you choose? Comment: I would consider taking some of the feedback, instead of asking others to write a paper, I for one am not going to write a paper In r7, we considered many design options � and we ended up with this templated design Comment: GTK and KDE use case The backend can support multiple implementations � but it is up to the implementer of the back end Q: How does all of this affect portability? Each implementer needs to create implementation for as many different backends want to supported Comment: In chrono you can specify a default backend, in order to not right platform specific code. If we look at the screen, there is no conditional code Q: When as a user do I need to deal with back-ends If you you want to optimize for your platform Q: And how to I programmatically do that Cairo, Qt, WebAssembly are all supported Comment: The short answer is that you dont have to do anything, you just compile it Q: I think that also addresses the concerns of writing a 3P library, however I do wonder if the kind of header based using approach potentially makes it a little unstable � if the header is your entry point includes that default, and if a later point that default changes � and then you have linking problems. Does that sounds like a concern? I dont think so. If you have a DLL, with two different backends, the DLL will always pull in the correct backend. Comment: 3P libs cannot include io2d.h because you could get build time conflicts Depending on the order of you includes, it will change the behavior of client project Comment: Say I have another piece of code, and I want to build against a certain backend, if the 3P code #include io2d.h, I cant change it to depend on the different back end Comment: So you are talking about changing the using statement Comment: We are talking about changing the sharelibs Comment: If you want to use a particular bakend, you can use using Comment: but that means the 3P lib cant be written in terms of io2d.h The 3P lib would be written as a header library Comment: using is typedef Comment: lets say you have a platform with muliple backends Comment: you imply you make the selection by using io2d.h will be provided by the vendor for there default backend, if you want a 3P with usings that would be differently named Comment: so you dont see core platforms offering multiple of these. If you have a 3P library that wraps this and has 1 selection for this given platform � you potentially end of with clashing using statements only std lib implementers are allowed to put something in the std namespace Comment: that will work Q: I would like to talk about BasicPathBuilder, this is a superset of std::vector. Containers are the most expensive type to standardise. I would suggest, take all of the functionality in BasicPathBuilder and create standalone free functions, and then use vector. These standalone functions will rely on ranges and iterators? Comment: It is a very specific container I did not realize standardizing a container was expensive Comment: It is very expensive. Also expensive to maintain Could it be a container adapter Comment: I believe a container adapter would be fine Comment: You brought this forward before, and I believe we told you to get rid of that Comment: You have provided us a use case that supports back-ends. You should be search for the minimal set of functionality that will reduce the chance for have a breaking change later If you cut of basic_ it will remove the ability to use using Q: Are you talking about what we would call PathBuilder? Comment: He is folloiwng precedent Q: If basic_image_surface, what do we call that with using? Q: we could follow what random did? that would be ok for the random example, all of the potential algorithms are library implemented Comment: I dont think included basic_ is a problems Comment: I am looking for a basic operation that is blitting. That is a basic thing you can do. We had blitting, and LEWG voted removing it Q: Do you remember the reason? It was deemed too complicated We support sprites through surfaces Comment: I think that Bryce and Titus need to get together and decide whether papers proposing container adapters Comment: I am recommending that this paper come back with no containers or container adapters, however container adapters are better than containers My understanding is that LEWG tries to be bound by past votes I would rather have the LEWG tell us that they dont want container and switch on their previous vote. Comment: This paper did not have consensus the last time it went to LEWG This paper won't pass through LEWG if it is in the same form as it was when there was not consensus P1200 stated that multiple NBs ... Comment: I understand P1200, but the fact remains that there was not consensus the last time this paper went through LEWG, and there needs to be changes made in order for their to be a different result next time [ to the room as the meeting adjourns ] Feel free to email the paper author the changes you would like to see
Received on 2019-07-23 14:56:24