Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Hi, I'd like to request a QUIP number for the handling of 3rd party code in Qt repositories. Anyhow, it seems to me that we're stuck currently in the bootstrapping process of QUIPs: http://quips-qt-io.herokuapp.com/quip-0003.html >The minimum QUIP boostrapping process was discussed: > >1. Post QUIP 1 to qt-development mailing list for discussion. >2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io has >since been made available) >3. Create new git repository to hold QUIPs So I'd like to request a gerrit repository for holding QUIPs, .e.g codereview.qt-project.org/qt/quips.git . Regards Kai > -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Tero Kojo > Sent: Monday, September 26, 2016 9:01 AM > To: Louai Al-Khanji ; development@qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > Hi, > > This initiative is much appreciated, thank you Louai! > Having been in the session at QtCon, I don't have any problems with the > proposed format and process as outlined in the initial QUIPS. > > I'd like to request two QUIP numbers "Qt Community Code of Conduct", and > another one for "Code of Conduct for Qt Events". > I guess the repo isn't there yet, do we wait on the lazy agreement process > until it is created? > > Tero > > > -Original Message- > > From: Development [mailto:development-bounces+tero.kojo=qt.io@qt- > > project.org] On Behalf Of Louai Al-Khanji > > Sent: tiistai 20. syyskuuta 2016 1.45 > > To: development@qt-project.org > > Subject: [Development] QCS2016 Session Notes - QUIPs for Qt > > > > Hi all, > > > > Here are my notes from the QUIPs session. Thank you for your patience. > > :-) > > > > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > > > QUIP 1 introduces the general concept: > > > > http://quips-qt-io.herokuapp.com/quip-0001.html > > > > QUIP 2 details the Qt governance model, it’s simply the current wiki > > page converted into a QUIP: > > > > http://quips-qt-io.herokuapp.com/quip-0002.html > > > > QUIP 3 is an informational QUIP containing the session notes, which > > are repeated below: > > > > http://quips-qt-io.herokuapp.com/quip-0003.html > > > > The heroku domain is obviously a placeholder. > > > > I have also attached the source files for proposed QUIPs 1, 2, and 3 > > to this e- mail. > > > > One item left open was licensing of the QUIPs themselves. For these I > > propose Creative Commons CC0. > > > > Any and all feedback welcome. > > > > Cheers, > > Louai > > > > BEGIN NOTES > > > > At the Qt Contributors' Summit 2016 in Berlin a session was held to > > discuss the idea of introducing QUIPs as a new process for Qt governance. > > > > The general idea was introduced by looking at QUIPs 1 and 2, and by > > looking at some Python PEPs. The general feedback was positive. An > > attempt was made to identify the minimum set of work required to > > bootstrap QUIP, which was the main theme of the session. > > > > The overall discussion is summarized below, in roughly chronological order. > > > > - Discussed background of QUIP, the process and the documents. > > Referred to > > Python and looked at QUIP 1 and QUIP 2 which had been prepared prior > > to the > > session. > > > > - The idea is to have a new git repository with the QUIP text files > > > > - Managed through Qt's normal work flow, currently gerrit code > > review > > > > - The maintainer of the quips repository takes on required editorial > > duties > > - Agreed that the text documents should be limited to 80 character lines. > > > > - Agreed that care must be taken to ensure that QUIPs are written in > > "proper" > > English so as to be clear, understandable and concise. > > > > - Talked about how a new QUIP is introduced. The most important thing is > to > > reserve a number, which is the identifier of any one QUIP. The title can > > change, and is expected to do so from time to time. > > > > - New QUIP documents will go through a review process like any other > > patch to > > Qt. The author of the QUIP is responsible for logging this discussion in > > the > > evolving QUIP itself. > > > > - The important thing is to bootstrap the process. Once it is bootstrapped, > > it > > is possible to fine-tune the QUIP process through QUIPs. It is expected > that > > this will happen. > > > > - The question of what goes into a QUIP was discussed. QUIP 1 gives a > rough > > overview of the different kinds of possible QUIPs. It is expected that the > > content be further specified in revisions of QUIP 1 or in follow-up QUIPs. > > > > - Like any other part of Qt, QUIPs are living documents. They can be > updated, > > amended or entirely superseded by later ones. > > > > - QUIP licensing was discussed. Python's PEPs are required to be > > either placed > > in the public domain or licensed under th
Re: [Development] Compile errors, Qt configured with -qreal float
On quinta-feira, 27 de outubro de 2016 08:23:57 PDT Marc Mutz wrote: > And, again, by proprietarily extending a perfectly adequate std > functionality, we lock ourselves deeper into our NIHS, losing new > functionality provided by newer std versions, in this case: variadic > std::min/max. Hm... you're actually right. We should use std::min and std::max since we can now rely on them existing and being properly implemented. I don't know a Standard Library equivalent of qBound, but I wasn't fixing that one due to too many permutations. We should drop qMin and qMax like we have the QtAlgorithms header. I trust you checked VS 2013 and Dinkumware. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile errors, Qt configured with -qreal float
> Am 27.10.2016 um 08:23 schrieb Marc Mutz : > >> On Thursday 27 October 2016 01:23:15 Thiago Macieira wrote: >> On quinta-feira, 27 de outubro de 2016 00:49:21 PDT Ola Røer Thorsen wrote: https://codereview.qt-project.org/175025 >>> >>> That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be >>> careless about mixing floats and doubles? I think it's a good practice to >>> avoid mixing when possible, with regards to performance especially on >>> smaller embedded devices. >> >> Yes and no. qMax and qMin have been the bane of qreal for the last 10 years >> because they are template functions. Solving those two will solve 95%+ of >> the qreal=float issues. That means the chance of having a release that >> fails to build under that condition lessens considerably. > > And, again, by proprietarily extending a perfectly adequate std > functionality, > we lock ourselves deeper into our NIHS, losing new functionality provided by > newer std versions, in this case: variadic std::min/max. > And depend more and more on different std implementations that introduce different behavior on different platforms and compilers? And let external software (that gcc issue is not that long in the past) break Qt's binary compatibility? Personally, I always prefer the uniform Qt style as I can rely on that platform and compiler independent functionality. Also I prefer code that looks like made out of a single piece. I don't like to incorporate x different libraries with x different coding and API styles. If so, I could also go and use GTK *ugh* Just my 2 cents ;) Best regards, Alexander Nassian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile errors, Qt configured with -qreal float
On Thursday 27 October 2016 01:23:15 Thiago Macieira wrote: > On quinta-feira, 27 de outubro de 2016 00:49:21 PDT Ola Røer Thorsen wrote: > > > https://codereview.qt-project.org/175025 > > > > That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be > > careless about mixing floats and doubles? I think it's a good practice to > > avoid mixing when possible, with regards to performance especially on > > smaller embedded devices. > > Yes and no. qMax and qMin have been the bane of qreal for the last 10 years > because they are template functions. Solving those two will solve 95%+ of > the qreal=float issues. That means the chance of having a release that > fails to build under that condition lessens considerably. And, again, by proprietarily extending a perfectly adequate std functionality, we lock ourselves deeper into our NIHS, losing new functionality provided by newer std versions, in this case: variadic std::min/max. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile errors, Qt configured with -qreal float
On quinta-feira, 27 de outubro de 2016 00:49:21 PDT Ola Røer Thorsen wrote: > > https://codereview.qt-project.org/175025 > > That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be > careless about mixing floats and doubles? I think it's a good practice to > avoid mixing when possible, with regards to performance especially on > smaller embedded devices. Yes and no. qMax and qMin have been the bane of qreal for the last 10 years because they are template functions. Solving those two will solve 95%+ of the qreal=float issues. That means the chance of having a release that fails to build under that condition lessens considerably. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile errors, Qt configured with -qreal float
2016-10-26 23:20 GMT+02:00 Thiago Macieira : > On quarta-feira, 26 de outubro de 2016 17:40:52 PDT Sergio Martins wrote: > > That's not enough and probably just 10% of the cost of the solution. One > > also needs to figure the contribution process and commit. The problem > > here is not technical, it's about inertia. > > I diidn't mean that Ola should contribute the fix. I was merely pointing > out > the fix for whoever will have to fix the issue. > > I tried fixing it anyway :-) https://codereview.qt-project.org/#/c/175026/ https://codereview.qt-project.org/#/c/175029/ In any event, this change in qtbase will help too (5.8 only): > https://codereview.qt-project.org/175025 > > That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be careless about mixing floats and doubles? I think it's a good practice to avoid mixing when possible, with regards to performance especially on smaller embedded devices. Cheers, Ola ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile errors, Qt configured with -qreal float
On quarta-feira, 26 de outubro de 2016 17:40:52 PDT Sergio Martins wrote: > On 2016-10-26 16:01, Thiago Macieira wrote: > > On quarta-feira, 26 de outubro de 2016 10:18:49 PDT Ola Røer Thorsen > > > > wrote: > >> I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from > >> source > >> when configuring Qt with -qreal float and building using g++ on Linux. > >> The > >> affected modules are Charts and Location. > >> > >> https://bugreports.qt.io/browse/QTBUG-56715 > >> > >> I would think that this should be given a higher priority than P3. I > >> initially reported this for 5.6.2 using a cross compile arm toolchain, > >> but > >> now I see it also affects 5.8 beta on the desktop. > >> > >> If -qreal float is a supported configuration, shouldn't this have been > >> caught in the CI system automatically? > > > > We don't test every module with every configuration. It's just too many > > permutations possible. > > > > Thanks for reporting, those issues are easy to fix. The line in > > > > question is: > > bottomRight.setLatitude(qMax(bottomRight.latitude(), > > -85.05113)); > > > > To fix this, the literal number needs to be written as: > > qreal(-85.05113). > > There's also a qMin line right above with the same problem. > > That's not enough and probably just 10% of the cost of the solution. One > also needs to figure the contribution process and commit. The problem > here is not technical, it's about inertia. I diidn't mean that Ola should contribute the fix. I was merely pointing out the fix for whoever will have to fix the issue. In any event, this change in qtbase will help too (5.8 only): https://codereview.qt-project.org/175025 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile errors, Qt configured with -qreal float
On 2016-10-26 16:01, Thiago Macieira wrote: On quarta-feira, 26 de outubro de 2016 10:18:49 PDT Ola Røer Thorsen wrote: I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from source when configuring Qt with -qreal float and building using g++ on Linux. The affected modules are Charts and Location. https://bugreports.qt.io/browse/QTBUG-56715 I would think that this should be given a higher priority than P3. I initially reported this for 5.6.2 using a cross compile arm toolchain, but now I see it also affects 5.8 beta on the desktop. If -qreal float is a supported configuration, shouldn't this have been caught in the CI system automatically? We don't test every module with every configuration. It's just too many permutations possible. Thanks for reporting, those issues are easy to fix. The line in question is: bottomRight.setLatitude(qMax(bottomRight.latitude(), -85.05113)); To fix this, the literal number needs to be written as: qreal(-85.05113). There's also a qMin line right above with the same problem. That's not enough and probably just 10% of the cost of the solution. One also needs to figure the contribution process and commit. The problem here is not technical, it's about inertia. The real issue understanding is "why don't users contribute trivial changes that they need". You see it all the time: - users complaining on a JIRA bug for 2 years instead of submitting a one-liner - users reporting wiki typo instead of editing wiki - users refusing to contribute because "I'm not a Qt developer" - users feeling entitled to a warranty - users not understanding that the qt-project has different responsibilities than TQC Ofc, this is not about Ola Thorsten, it's about our project and how we communicate with users. Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile errors, Qt configured with -qreal float
On quarta-feira, 26 de outubro de 2016 10:18:49 PDT Ola Røer Thorsen wrote: > I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from source > when configuring Qt with -qreal float and building using g++ on Linux. The > affected modules are Charts and Location. > > https://bugreports.qt.io/browse/QTBUG-56715 > > I would think that this should be given a higher priority than P3. I > initially reported this for 5.6.2 using a cross compile arm toolchain, but > now I see it also affects 5.8 beta on the desktop. > > If -qreal float is a supported configuration, shouldn't this have been > caught in the CI system automatically? We don't test every module with every configuration. It's just too many permutations possible. Thanks for reporting, those issues are easy to fix. The line in question is: bottomRight.setLatitude(qMax(bottomRight.latitude(), -85.05113)); To fix this, the literal number needs to be written as: qreal(-85.05113). There's also a qMin line right above with the same problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clangbackend qtcreator 4.2 memory hogging
so I'm now just thinking the possibility to pack list of clang symbol internal chunk of class to be serialized into qdatastream binary and send it over sqlite column. But this is just my dummy thought. Could you please possibly integrate this project http://rprichard.github.io/sourceweb/ into qtcreator as well. I had succeed with it readonly indexing my production project at 60k SLOC and the whole nodejs project source tree with it's dependency project like openssl, v8 js ,libuv etc... @Marco Bubke what do you think, they have friendly BSD license mainly btw? On 10/26/16, Marco Bubke wrote: > If c++ modules becomes supported it could go down but actually you should > request that in the clang mailling list. We open a translation unit for > every file and they are that big. We research precompiled header to improve > speed and maybe they provide advantages in memory usage too. > > > From: Development on > behalf of kang joni > Sent: Wednesday, October 26, 2016 11:57:55 AM > To: development@qt-project.org > Subject: [Development] clangbackend qtcreator 4.2 memory hogging > > I have small project in which contains 2k SLOC with heavy v8 js > template included in source file. > For small opening 3-4 sources file this take almost 870mb in memory > with no precompiled header being checked plus qtcreator eats 280mb > with 2gb Intel celeron and this is definitely not desirable for me. I > have feature request whether is this possible to put heavy c++ symbol > data in sqlite file with multithread concurrent access mechanism > instead to keep clangbackend memory usage being low? > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clangbackend qtcreator 4.2 memory hogging
If c++ modules becomes supported it could go down but actually you should request that in the clang mailling list. We open a translation unit for every file and they are that big. We research precompiled header to improve speed and maybe they provide advantages in memory usage too. From: Development on behalf of kang joni Sent: Wednesday, October 26, 2016 11:57:55 AM To: development@qt-project.org Subject: [Development] clangbackend qtcreator 4.2 memory hogging I have small project in which contains 2k SLOC with heavy v8 js template included in source file. For small opening 3-4 sources file this take almost 870mb in memory with no precompiled header being checked plus qtcreator eats 280mb with 2gb Intel celeron and this is definitely not desirable for me. I have feature request whether is this possible to put heavy c++ symbol data in sqlite file with multithread concurrent access mechanism instead to keep clangbackend memory usage being low? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] clangbackend qtcreator 4.2 memory hogging
I have small project in which contains 2k SLOC with heavy v8 js template included in source file. For small opening 3-4 sources file this take almost 870mb in memory with no precompiled header being checked plus qtcreator eats 280mb with 2gb Intel celeron and this is definitely not desirable for me. I have feature request whether is this possible to put heavy c++ symbol data in sqlite file with multithread concurrent access mechanism instead to keep clangbackend memory usage being low? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Coin news
On Wed, Oct 26, 2016 at 08:47:48AM +0200, Marc Mutz wrote: > On Tuesday 25 October 2016 10:55:34 Oswald Buddenhagen wrote: > > On Tue, Oct 25, 2016 at 07:22:41AM +, Jędrzej Nowacki wrote: > > > I would like to also remind everyone, that intermodule API changes need > > > to be merged in two steps. For example if you plan to change a method > > > "void foo()" in qtbase to "void foo(const QString&)", that would be the > > > right order of execution: 1. Commit a change to qtbase that _adds_ > > > foo(const QString&) > > > > 1a. wait for qt5 integration. 2 would not integrate in the submodules > > without 1 being in qt5 already. > > > > > 2. Update all modules that use foo() to use foo(const QString&) > > > 3. Wait until Qt5(dev branch) submodule update, that gathers changes from > > > 1 and 2 > > > > only 2 at this point. > > > > > 4. Remove old foo() from qtbase > > > > 4a. wait again until the final qt5 integration to see it in packages. > > > > so six steps in total. and it takes exactly as long as it sounds. > > > > > If you do not follow we would have to revert your changes. > > Alternatively, #define a macro in the upstream module when adding the new > API, > and check for it in the downstream module to decide which API to use. These > two changes can then proceed independently, followed at any time after just > one qt5.git integration by two clean-up commits. > that's indeed better in the optimal case: 1. prepare downstream module and update upstream module 2. have them integrated into qt5. make sure that the upstream update does not go in before the downstream adjustment (you can generally assume an atomic integration). 3. clean up both modules 4. have them integrated into qt5. make sure the upstream cleanup does not go in before the downstream cleanup. another good thing about this variant is that you can atomically fix issues introduced due to signal/slot overloading, which you'd otherwise have to do separately in advance, introducing yet another two-stage integration. a downside is that the history is messier, because there are inherently at least two commits in every downstream module. and it may get even more messy if you notice later in the process that you need to adjust the downstreams further before the qt5 integration succeeds. that's because the downstream integrations are basically dummies and you don't notice that something went wrong until the qt5 integration which pulls in the upstream change. > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWebChannel: Upstreaming of Python client
On 25.10.2016 13:36, Johannes Lochmann wrote: Hi Arno, On 24 October 2016 at 00:53, Arno Rehn wrote: Hey everybody, At my company we've developed a Python client for QtWebChannel. It consists of a more or less direct translation of qwebchannel.js and an additional layer on top of it, providing async/await syntax support for Python3.5+. Ideally, we'd like to push this upstream. Before I post a patch to gerrit, I'd like to get some feedback on whether this is wanted at all. QtWebChannel seems to be pretty much focused on HTML and the web, but the infrastructure behind it can be used for remoting from pretty much any scripting language. I'd also plan on implementing a C++ client, maybe also Ruby and Matlab (since we're using this in a scientific setting). What's your take on this? Seems useful. Would be interested to try it out. I agree, this sounds pretty useful, especially given that we’re also working again on pyside since this spring. ...especially an implementation in Python and C++ both from the Qt Project could be a really nice combo - sign me up! Thanks for all the feedback! Nice to know that people are interested :) I'll polish the code a little and create a review request. Regards, -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.r...@menlosystems.com www.menlosystems.com Menlo Systems GmbH Am Klopferspitz 19a, 82152 Martinsried, Germany Amtsgericht München HRB 138145 Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr. DE217772017, St.-Nr. 14316170324 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Compile errors, Qt configured with -qreal float
I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from source when configuring Qt with -qreal float and building using g++ on Linux. The affected modules are Charts and Location. https://bugreports.qt.io/browse/QTBUG-56715 I would think that this should be given a higher priority than P3. I initially reported this for 5.6.2 using a cross compile arm toolchain, but now I see it also affects 5.8 beta on the desktop. If -qreal float is a supported configuration, shouldn't this have been caught in the CI system automatically? Cheers, Ola Røer Thorsen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL Issues in Qt5.7
And now Gunnar has just pointed out there is work in this area: :) https://codereview.qt-project.org/#/c/166202/ Cheers, Sean On 26/10/2016 08:54, Sean Harmer wrote: Hi, On 26/10/2016 08:21, Kai Koehne wrote: -Original Message- From: Liu, Jeff (SRDC SW) [mailto:jeff1@amd.com] Sent: Wednesday, October 26, 2016 7:09 AM To: gunnar.sle...@jollamobile.com; gun...@sletta.org; Liang Qi ; Kai Koehne ; development@qt- project.org Subject: RE: OpenGL Issues in Qt5.7 Spread to Qt mail-list to ask for help. From: Liu, Jeff (SRDC SW) Sent: Tuesday, October 25, 2016 2:26 PM To: 'gunnar.sle...@jollamobile.com'; 'gun...@sletta.org'; 'liang...@qt.io'; 'kai.koe...@qt.io' Subject: OpenGL Issues in Qt5.7 Hi Sletta, Qi and Koehne, Hi Jeff! This is Jeff from AMD, recently a customer reports a game issue with AMD cards, but the game runs well on Nvidia card, after some debug, I find out that the issues are caused by Qt libraries, when Qt programs with OpenGL API, it doesn’t follow the OpenGL programming specification strictly, so it will report errors on AMD platform. Now we find out the two following issues, both issues come from Qt paint engine. 1. QTBUG-56234 - OpenGL glVertexAttribArray API usage error in Qt5Guid.dll I submit a ticket to address this issue, and this issue is assigned to Sletta, but it seems no one starts to work on it, the usage of glVertexAttribArray API is wrong, it is still used in the old way (OpenGL 3.0), but it apparently violate the latest OpenGL specification (OpenGL 4.1) Liang already commented on this one. Laszlo (the new assignee) probably has a better idea about this, too. As commented on the bug, this QOpenGL2PaintEngine is only meant for use with a 2.x OpenGL context. The paint engine will not work properly with a Core Profile context. All the shaders are also legacy (attribute + varying vs in + out). 2. I don’t submit the ticket for the second issue yet, Qt paint engine uses GL_RED to upload the texture, so based on the spec, the texture will be (GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, which is a constant 0 value in AMD platform, if changed to src * mask.r, then everything will be correct, I will submit a ticket to address it later. Feel free to report this, too. Again, this would really require a new OpenGL paint engine for modern OpenGL to be written. Afaik nobody is working on this or even looking into it. Using Qt Quick 2 would be an easier path if it suits your use case. I'd love to have the ability to composite widget painting with modern GL so if you want to work on such a thing then please do feel free to do so. Cheers, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL Issues in Qt5.7
Hi, On 26/10/2016 08:21, Kai Koehne wrote: -Original Message- From: Liu, Jeff (SRDC SW) [mailto:jeff1@amd.com] Sent: Wednesday, October 26, 2016 7:09 AM To: gunnar.sle...@jollamobile.com; gun...@sletta.org; Liang Qi ; Kai Koehne ; development@qt- project.org Subject: RE: OpenGL Issues in Qt5.7 Spread to Qt mail-list to ask for help. From: Liu, Jeff (SRDC SW) Sent: Tuesday, October 25, 2016 2:26 PM To: 'gunnar.sle...@jollamobile.com'; 'gun...@sletta.org'; 'liang...@qt.io'; 'kai.koe...@qt.io' Subject: OpenGL Issues in Qt5.7 Hi Sletta, Qi and Koehne, Hi Jeff! This is Jeff from AMD, recently a customer reports a game issue with AMD cards, but the game runs well on Nvidia card, after some debug, I find out that the issues are caused by Qt libraries, when Qt programs with OpenGL API, it doesn’t follow the OpenGL programming specification strictly, so it will report errors on AMD platform. Now we find out the two following issues, both issues come from Qt paint engine. 1. QTBUG-56234 - OpenGL glVertexAttribArray API usage error in Qt5Guid.dll I submit a ticket to address this issue, and this issue is assigned to Sletta, but it seems no one starts to work on it, the usage of glVertexAttribArray API is wrong, it is still used in the old way (OpenGL 3.0), but it apparently violate the latest OpenGL specification (OpenGL 4.1) Liang already commented on this one. Laszlo (the new assignee) probably has a better idea about this, too. As commented on the bug, this QOpenGL2PaintEngine is only meant for use with a 2.x OpenGL context. The paint engine will not work properly with a Core Profile context. All the shaders are also legacy (attribute + varying vs in + out). 2. I don’t submit the ticket for the second issue yet, Qt paint engine uses GL_RED to upload the texture, so based on the spec, the texture will be (GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, which is a constant 0 value in AMD platform, if changed to src * mask.r, then everything will be correct, I will submit a ticket to address it later. Feel free to report this, too. Again, this would really require a new OpenGL paint engine for modern OpenGL to be written. Afaik nobody is working on this or even looking into it. Using Qt Quick 2 would be an easier path if it suits your use case. I'd love to have the ability to composite widget painting with modern GL so if you want to work on such a thing then please do feel free to do so. Cheers, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL Issues in Qt5.7
> -Original Message- > From: Liu, Jeff (SRDC SW) [mailto:jeff1@amd.com] > Sent: Wednesday, October 26, 2016 7:09 AM > To: gunnar.sle...@jollamobile.com; gun...@sletta.org; Liang Qi > ; Kai Koehne ; development@qt- > project.org > Subject: RE: OpenGL Issues in Qt5.7 > > > > Spread to Qt mail-list to ask for help. > > > > From: Liu, Jeff (SRDC SW) > Sent: Tuesday, October 25, 2016 2:26 PM > To: 'gunnar.sle...@jollamobile.com'; 'gun...@sletta.org'; 'liang...@qt.io'; > 'kai.koe...@qt.io' > Subject: OpenGL Issues in Qt5.7 > > > > Hi Sletta, Qi and Koehne, Hi Jeff! > This is Jeff from AMD, recently a customer reports a game issue with AMD > cards, but the game runs well on Nvidia card, after some debug, I find out > that the issues are caused by Qt libraries, when Qt programs with OpenGL > API, it doesn’t follow the OpenGL programming specification strictly, so it > will > report errors on AMD platform. > > Now we find out the two following issues, both issues come from Qt paint > engine. > > 1. QTBUG-56234 - OpenGL glVertexAttribArray API usage error in > Qt5Guid.dll > > I submit a ticket to address this issue, and this issue is assigned to > Sletta, but > it seems no one starts to work on it, the usage of glVertexAttribArray API is > wrong, it is still used in the old way (OpenGL 3.0), but it apparently > violate the > latest OpenGL specification (OpenGL 4.1) Liang already commented on this one. Laszlo (the new assignee) probably has a better idea about this, too. > 2. I don’t submit the ticket for the second issue yet, Qt paint engine > uses > GL_RED to upload the texture, so based on the spec, the texture will be > (GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, which is a > constant 0 value in AMD platform, if changed to src * mask.r, then everything > will be correct, I will submit a ticket to address it later. Feel free to report this, too. > I don’t know what’s the right way to report and fix Qt issues, there may be > more issues later in the game, so I write an email to you guys (I find your > emails from code.qt.io), please tell me what should I do to co-work with you > and make these issues fixed. Reporting them on bugreports.qt.io is certainly a good start :) If you're a commercial customer you should also go through Qt Support - often enough the support team can help directly, or escalate things. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.8.0 Beta packages available for testing
On 25/10/16 20:43, "Development on behalf of Thiago Macieira" wrote: >On terça-feira, 25 de outubro de 2016 18:12:27 PDT Massimo Callegari via >Development wrote: >> > It was never supported, therefore it can't be a bug, much less a >> > regression. Indeed we removed some functionality, but one that was >> > technically abusing >> > qmake because it wasn't supported. >> >> That is not true. See the official Qt documentation, end of page, >> "Configuration Features" paragraph: >> http://doc.qt.io/qt-5/qmake-project-files.html >> >> Honestly I don't care much if it was there by mistake or unsupported or >> whatever. It was a usable feature. Period. > >By abusing qmake. Your bug report showed you used this line: > >macx:QT_CONFIG -= no-pkg-config > >That above is the abuse. Show us code that worked without that line and has >stopped working. That will qualify as a regression. > >You can continue to abuse Qt's configuration in 5.8. It just changed what >variables you have to abuse. No compatiblity is guaranteed because it's an >abuse. > >> As I stated before, pkg-config is fundamental to access libraries outside of >> Qt's scope, either on Linux, MSYS2 on Windows or Homebrew/Macports on Mac >> OS, so we need to keep on having that feature from Qt. > >I'm not disputing that. That's why I reopened the issue and made it a feature >request so that we officially support it, without abuses required. > >> If you want developers to stop having such access, then I would much like >> call it a regression and IMHO it should be fixed before releasing Qt 5.8.0. > >It wasn't a feature before, therefore it's not a bug and not a regression. > >Alternatively, we can call it a bug that has been present for a long time. It >still wouldn't be a regression. Agree with Thiago. Having said that, as we have been doing quite many changes to the configuration system, let’s see if we can get this fixed somewhat properly for 5.8 final. But it’s not a blocker for the beta. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development