Re: [Development] Supported compilers for Qt 6
14.08.2019, 23:53, "Allan Sandfeld Jensen" : > On Tuesday, 13 August 2019 18:13:05 CEST Thiago Macieira wrote: >> On Tuesday, 13 August 2019 00:50:48 PDT Friedemann Kleint wrote: >> > Hi, >> > >> > > VC++ 2019 >> > >> > Just for the record, this compiler still has a number of optimizer bugs, >> > see https://bugreports.qt.io/browse/QTQAINFRA-2875 . >> >> Unfortunately, despite those, it's still the best available. MSVC 2017 has >> *serious* problems with static libraries (as in, crash on start) and MSVC >> 2015 is too old. > > Note btw, that referring to the major year numbers of MSVC might be an > obsolete way of thinking. MSVC 2017 started with only C++11 support but gained > up to almost full C++17 in patches. Also introducing bugs, causing regressions in valid code in its minor updates, e.g. https://developercommunity.visualstudio.com/content/problem/343550/webkit-an-undefined-class-is-not-allowed-as-an-arg.html > MSCV 2019 is new is so far mostly the > same as MSVC 2017 ended up as, but it seems likely to also improve greatly in > point releases. > > 'Allan > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Supported compilers for Qt 6
On Tuesday, 13 August 2019 18:13:05 CEST Thiago Macieira wrote: > On Tuesday, 13 August 2019 00:50:48 PDT Friedemann Kleint wrote: > > Hi, > > > > > VC++ 2019 > > > > Just for the record, this compiler still has a number of optimizer bugs, > > see https://bugreports.qt.io/browse/QTQAINFRA-2875 . > > Unfortunately, despite those, it's still the best available. MSVC 2017 has > *serious* problems with static libraries (as in, crash on start) and MSVC > 2015 is too old. Note btw, that referring to the major year numbers of MSVC might be an obsolete way of thinking. MSVC 2017 started with only C++11 support but gained up to almost full C++17 in patches. MSCV 2019 is new is so far mostly the same as MSVC 2017 ended up as, but it seems likely to also improve greatly in point releases. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Supported compilers for Qt 6
On 2019-08-13 09:50, Friedemann Kleint wrote: > VC++ 2019 Just for the record, this compiler still has a number of optimizer bugs, see https://bugreports.qt.io/browse/QTQAINFRA-2875 . Also JFTR: Peppe found one of the bugs rumoured to be a MSVC bug was a problem in _our_ code, the compiler just took advantage of UB :) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt PDF as a new TP module for Qt 5.14
On Wednesday, 14 August 2019 09:36:44 PDT Allan Sandfeld Jensen wrote: > On Wednesday, 14 August 2019 17:00:51 CEST Shawn Rutledge wrote: > > > On 14 Aug 2019, at 16:41, Thiago Macieira > > > wrote: > > > > > > If it uses the already-compiled qtwebengine, then there may be a way. > > > > I think the point of bundling qtpdf into the qtwebengine repository is > > that > > they will be built together, from the same sources. I hope it also means > > that the same Pdfium shared object will be used by both, at runtime, but > > maybe somebody can confirm that? > > Same sources, and maybe even same the object files during building, but at > the moment they end up as two different modules. We don't have a pdfium > shared library, and it is not on our timeline. That's ok, so long as both libraries get built from the same .tar.xz. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt PDF as a new TP module for Qt 5.14
On Wednesday, 14 August 2019 17:00:51 CEST Shawn Rutledge wrote: > > On 14 Aug 2019, at 16:41, Thiago Macieira > > wrote: > > > > If it uses the already-compiled qtwebengine, then there may be a way. > > I think the point of bundling qtpdf into the qtwebengine repository is that > they will be built together, from the same sources. I hope it also means > that the same Pdfium shared object will be used by both, at runtime, but > maybe somebody can confirm that? Same sources, and maybe even same the object files during building, but at the moment they end up as two different modules. We don't have a pdfium shared library, and it is not on our timeline. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt PDF as a new TP module for Qt 5.14
On 13 Aug 2019, at 18:11, Thiago Macieira mailto:thiago.macie...@intel.com>> wrote: On Tuesday, 13 August 2019 02:20:04 PDT Shawn Rutledge wrote: When it comes to Qt Quick, either solution can be exposed either as a subclass of QImageIOHandler (so that it “just works” as an image format) or QQuickImageProvider. Wait, what? Why would you do it via *image* handlers? Because when we ask PDFium to render a page for us, it uses Skia to do that. The easiest way to render a page (the only way we support so far) is to get back an image for the whole page, and then stick it in the scene graph, or paint it into a widget. Even if we later can figure out how to use QPainter, we can still end up with an image. Even later, maybe we can figure out how to use the scene graph to render individual glyphs, individual images that the PDF contains, individual vector graphics if the PDF contains line drawings, etc. But it’s rather like the situation with SVG: we should perhaps ideally break it up into some sort of DOM and render all the stuff that the SVG contains, but instead we just treat it as an image format, because qtsvg knows how to use QPainter to render an SVG to an image. Nevertheless we still get the benefit of scalability (you can zoom in to an SVG in Qt Quick, and make it render sharper as you do so, by re-rendering the whole thing at higher resolution. And yes you pay the memory and time penalties for doing that.) It might even turn out to be more efficient the way we are doing it: take the CPU hit to make a big texture once, and from then on there’s just one texture node in the scene graph, rather than creating thousands of scene graph nodes to compose the page and re-rendering those at 60fps. Most of PDF is text. Is PDFium and the proposed module capable of selecting text, copy it to the clipboard, show the document structure, etc.? That will come soon: it’s on the requirements list to be able to select and copy text. PDFium provides API to get the character index at a location, the string from one index to another, and the geometry from one index to another. So I think I will implement it by letting the user drag across the page, find the geometry of the text that is being thus selected, render a translucent rectangle on top to show that it’s selected, and allow copying that text to the clipboard. PDF text rendering is complicated, I’m afraid. Various kerning strategies are possible (including putting every glyph at its own independent position, as it appears to be when you render from latex to PDF). Adobe used to advertise that there is a font-matching technique so that anyone on any computer can render a decent approximation of a document even if you don’t have the fonts that were used in the original. So I suspect it will be difficult to render text on top of a page and have the glyph geometry match up exactly to the glyphs that PDFium is rendering; but we will have to solve that problem if we later want to use QPainter to do the rendering. (I have seen really bad text rendering on Linux PDF viewers in the past. They have gotten way better over the years.) What I dislike about Pdfium so far is that it has its own raster engine to do the rendering: we can only get fully rendered images out of it so far, not QPainter calls. It may be that it’s faster or slower than it would be to use QPainter; but either way, it’s a kind of bloat to ship another internal paint engine. But who knows, if we want to spend the time we might be able to refactor it, depending on whether there is some way to get rendering callbacks out of it. I haven’t tried to figure that out either. Indeed, but it might be worth it. We won't know until someone posts the analysis. I want to figure that out at some point, but I don’t see how I can put such investigation at a higher priority than implementing features that we have commercial customers asking for (the time frame for which is ASAP). Of course anyone else is welcome to read the code and report what he or she can find out about how it’s all done internally. In 2017, a commenter on the blog post where qtpdf was announced (https://blog.qt.io/blog/2017/01/30/new-qtpdf-qtlabs-module/) pointed me to https://pdfium.googlesource.com/pdfium/+/master/core/fxge/skia/ , and https://github.com/amplab/ray-core/blob/master/src/examples/ui/pdf_viewer/pdf_viewer.cc as an example. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt PDF as a new TP module for Qt 5.14
On Wednesday, 14 August 2019 08:00:51 PDT Shawn Rutledge wrote: > > On 14 Aug 2019, at 16:41, Thiago Macieira > > wrote: > > > > If it uses the already-compiled qtwebengine, then there may be a way. > > I think the point of bundling qtpdf into the qtwebengine repository is that > they will be built together, from the same sources. I hope it also means > that the same Pdfium shared object will be used by both, at runtime, but > maybe somebody can confirm that? That would mitigate my concerns. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt PDF as a new TP module for Qt 5.14
> On 14 Aug 2019, at 16:41, Thiago Macieira wrote: > > If it uses the already-compiled qtwebengine, then there may be a way. I think the point of bundling qtpdf into the qtwebengine repository is that they will be built together, from the same sources. I hope it also means that the same Pdfium shared object will be used by both, at runtime, but maybe somebody can confirm that? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt PDF as a new TP module for Qt 5.14
On Tuesday, 13 August 2019 22:40:29 PDT Allan Sandfeld Jensen wrote: > On Wednesday, 14 August 2019 07:09:33 CEST Thiago Macieira wrote: > > On Tuesday, 13 August 2019 16:04:38 PDT Allan Sandfeld Jensen wrote: > > > That is exactly the same Chromium does. Except we already put the work > > > into > > > backporting the fixes. > > > > ALL of them? How quickly? > > > > Please make sure that either you're releasing within two weeks of *every* > > CVE or that I can use an unbundled copy of the source. Failing that, I > > cannot add qtpdf to Clear Linux. > > So you have higher requirement for PDF viewer than you do for browsers? No, it's the same: every High or Critical CVE fixed within two weeks of a fix being available. Regardless of whether the software in question made a release or not. qtwebengine is its own headache because we can't use the release tarballs from qt.io. We need to wait for Fedora to clean up the not-totally-free content inside[*] and publish sources. So for that one, our policy became "whatever Fedora has is good enough". But I will not add a new package like that. Chrome and Firefox are also installed in such a way that Google and Mozilla are responsible for updates. We don't currently have Chromium. > But yes all of them, but we are tied by how fast Qt releases. We do make > sure to fix the security issues before the details are made public, which > is 14 weeks after a Chrome version has been released with the fixed. If qtpdf uses chromium sources, it will not be added to the distro. You'll be marrying one of the worst offenders in terms of CVEs published (PDF engines) to the worst offender. I'll simply not take the chance, until at least my hand is forced by there being a lot of open source software trying to use it. If it uses the already-compiled qtwebengine, then there may be a way. [*] ffmpeg -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Repo request for Qt Quick 3D module
Hello everyone, As The Qt Company announced today on our blog, we have been working on creating a unified graphics story for our 2D and 3D Qt Quick API's and tooling. Part of this story is introducing a new module and API for defining 3D content in Qt Quick. https://blog.qt.io/blog/2019/08/14/introducing-qt-quick-3d-high-level-3d-api-qt-quick/ repo name: qtquick3d name: Qt Quick 3D responsible person: me (Andy Nichols) The code is currently hosted here: https://git.qt.io/annichol/qtquick3d This code represents the effort to start the process of integrating 3D content into Qt Quick's rendering, bound by the limitations of binary compatibility in Qt Declarative. The current code works against the Qt 5.12 LTS, and is a approximation of what we are trying to achieve as a whole. For Qt 6 we are planning to further integrate with the existing Qt Quick Scenegraph infrastructure so that more APIs can be shared (for example QSGTexture, QSGGeometry), as well as making it easier to have QQuickItem based components rendered in spatial contexts. There is a valid concern that this is yet another 3D solution for Qt, being that we currently are offering both Qt3D and Qt 3D Studio as supported solutions. As stated in the blog post, this isn't a replacement of Qt3D, as Qt3D is a low level API for creating 3D runtimes. With regard to Qt 3D Studio, this project is an evolution of that offering. Qt 3D Studio has the issue that the runtime it ships with overlaps very much so with Qt Quicks offering, while still leaving a lot of gaps in functionality that Qt Quick already provides. Rather than continuing to try and fill those gaps and fragment our HMI story further, we would rather extend Qt Quick to support a high level 3D API that Qt 3D Studio tries to provide. So with Qt Quick 3D we functionally have a QML API for using the features of Qt 3D Studio, while simultaneously enabling us to unify our tooling story for Qt Design Studio. Our goal is to reduce the amount of things we are working on in parallel, and focus our efforts on extending the functionality of Qt Quick. This goes hand-in-hand with the modernization of Qt Quick with the QtRHI work. We would like to provide a tech-preview of this module along with 5.14.0 and continue to develop the project further out in the open. Regards, Andy Nichols ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
