Re: [Development] Status of QtDeclarative on Windows?
Hi Todd, It looks like the qwindowsglcontext.cpp file does not request a swap interval of 1 anywhere, which would mean you have to pick the option "always vsync, regardless of what application requests"-option if such a thing exists. If you did this and it makes no difference then the driver is broken :) Another option is to disable the threaded renderer on windows using the environment variable QML_BAD_GUI_RENDER_LOOP, doing this would put it on par with X11/XCB. This is something we anyways need in order to support multiple toplevel QML windows as the current threaded implementation expects to block on a full buffer queue per window rather than swapBuffers to block immediately. The environment variable will switch to use the timer driven, GUI-only render loop. This also disables the vsync driven animations, but for a driver that ignores vsync, this is what we have to use. If we played nice, we would expose this behavior from the QPlatformIntegration / QPlatformGLContext so QtDeclarative could adapt properly, but we currently don't have API and implementation in place to catch this. cheers, Gunnar On Jan 16, 2012, at 1:45 AM, ext todd.r...@nokia.com wrote: > Well it looks like the slowness I'm seeing is due to the rendering thread > using all of the CPU. I tried toggling the nvidia driver settings for vsync > and triple-buffering but that doesn’t change the behavior. Is there anything > else I can try? Do other people see acceptable performance on Windows > currently? > > -Todd > >> -Original Message- >> From: development-bounces+todd.rose=nokia@qt-project.org >> [mailto:development-bounces+todd.rose=nokia@qt-project.org] On >> Behalf Of ext todd.r...@nokia.com >> Sent: Saturday, January 14, 2012 4:47 PM >> To: Storm-Olsen Marius (Nokia-MP/Austin); development@qt-project.org >> Subject: Re: [Development] Status of QtDeclarative on Windows? >> >> It seems equally slow when running debug and release libs, but will double >> check later this weekend to make sure it's not user-error. I think it has >> more >> to do with running with a video card that doesn't provide much (if any?) >> hardware acceleration. But I was assuming that even in that case that QML2 >> would be just as good as QML1. Clearly something is causing that to not be >> the case. >> >> What's the expectation when using video cards that don't offer OpenGL >> hardware acceleration? >> >> -Todd >> >>> -Original Message- >>> From: Storm-Olsen Marius (Nokia-MP/Austin) >>> Sent: Saturday, January 14, 2012 9:12 AM >>> To: development@qt-project.org; Rose Todd (Nokia-M/Alpharetta) >>> Subject: Re: [Development] Status of QtDeclarative on Windows? >>> >>> Are you sure you are at least running the release version of your >> application? >>> >>> Debug version uses the debug CRT libs (and a debug Qt which does the >>> same), so everything will be a lot slower than the end product. >>> >>> You cannot really evaluate performance with debug builds. >>> >>> -- >>> Sent from my Nokia N9 >>> On 1/13/12 23:12 ext todd.r...@nokia.com wrote: >>> Just for fun I’ve been playing with a medium-sized QML app that we had >>> written for 4.7/Symbian and porting it to Qt5/QML2. Mostly have been >>> working on Linux but the past few days I finally got around to >>> compiling Qt5 on Windows and playing around with the project enough so >>> that it would compile and run under qmlscene (it’s mostly qml/js with >>> a C++ plugin module as well). >>> >>> Anyway, the performance on my Windows box is horrible. ListView >>> scrolling, image loading, animations, everything is like it’s running >>> in quicksand. Is this expected? If not, what do I need to do to in >>> order to troubleshoot? This machine is relatively old and has a >>> crappy video card (older Nvidia Quadro), but it should be more than >>> good enough to run this app smoothly. Any tips or tricks to enable extra >> debug tracing? >>> >>> Thanks, >>> Todd >> ___ >> 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Role names and Proxy Models
On Friday, January 13, 2012 22:37:16 Johan Thelin wrote: > Hi all, > > I've been constructing a proxy model that hides multiple underlying > models. In this process, I have to translate the custom roles for each > model. E.g. the custom role enumeration for the duration of a music > track is not the same as for an album, but when accessed through my > proxy model, it should be. This is where I encountered an issue with > the current proxy models (in Qt 4.8). > > The role names for the model being proxied is copied each time > setModel is called. This means that the role names might change while > the model lives - something that does not work well with QML (as is > pointed out by the documentaiton). It also means that any calls to > setRoleNames in the c'tor of the proxy model are futile - the roles > are replaced when a model is set. > > In my opinion, this behavior should not be enforced at the current > level, i.e. in QAbstractProxyModel, but rather, in each specific > implementation, e.g. in QAbstractSortfFilterProxyModel, but not in > QIdentityProxyModel, so that a role-tranforming-proxy, like the one I > created, can be implemented. > > Introducing this in the 4.x tree might be considered to break the API, > but this is definitely something that I would like to see in Qt 5. > Does anyone object to this? Or is it time to submit a small patch? > I'm not sure what your actual proposal is? If a model changes its rolenames then it should emit signals about being reset. If it emits signals about being reset, then QML should re-read the rolenames (note that proxies are not relevant in those sentences - the relevant API is QAbstractItemModel). If QML doesn't re-read the rolenames when the model is reset, then there's a patch to be made in QtDeclarative. (QAbstractProxyModel doesn't re-read them on reset either. Ogoffart rejected my patch to make it do that for reasons which never made sense to me and which I now forget and can't find on the internet). Anyway the Qt 5.0 way to set rolenames is to implement a virtual method. Please see if that addresses your concern, and if it doesn't, then please write an example which doesn't require a proxy which hides 'multiple underlying models'. That might not work anyway for various reasons (if you are using QAbstractProxyModel). Use an example such as 'a proxy model which returns a string filename for an image instead of a QImage for the decoration role'. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On Sunday, 15 de January de 2012 20.25.17, Peter Kuemmel wrote: > Technically interesting here is the question how such a > situation cloud be managed? Using C++11 'final' would > prevent the reimplementation. But using pre C++11, the only > idea I have is to define a dummy function with a different > return value, only this why the compiler would complain. Actually, this *is* a solution. If we change the return value of the virtual createRequest to int and keep the arguments, someone trying to override it with the standard function would get a compiler error: :1:224: error: conflicting return type specified for ‘virtual QNetworkReply* Derived::createRequest(QNetworkAccessManager::Operation, const QNetworkRequest&, QIODevice*)’ :1:105: error: overriding ‘virtual int QNetworkAccessManager::createRequest(QNetworkAccessManager::Operation, const QNetworkRequest&, QIODevice*)’ We can use a return type like ThisFunctionIsDeprecated_InsteadPleaseOverride_createReply. That said, I don't think it's worth it. Just leave it alone. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On Sunday, 15 de January de 2012 23.09.35, John Layt wrote: > * A QCldrLocale is not really needed for Qt purposes, it's only needed for > anyone who wants to know what individual settings are, like KDE What would this class provide that the regular QLocale wouldn't? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QtDeclarative on Windows?
Well it looks like the slowness I'm seeing is due to the rendering thread using all of the CPU. I tried toggling the nvidia driver settings for vsync and triple-buffering but that doesn’t change the behavior. Is there anything else I can try? Do other people see acceptable performance on Windows currently? -Todd > -Original Message- > From: development-bounces+todd.rose=nokia@qt-project.org > [mailto:development-bounces+todd.rose=nokia@qt-project.org] On > Behalf Of ext todd.r...@nokia.com > Sent: Saturday, January 14, 2012 4:47 PM > To: Storm-Olsen Marius (Nokia-MP/Austin); development@qt-project.org > Subject: Re: [Development] Status of QtDeclarative on Windows? > > It seems equally slow when running debug and release libs, but will double > check later this weekend to make sure it's not user-error. I think it has > more > to do with running with a video card that doesn't provide much (if any?) > hardware acceleration. But I was assuming that even in that case that QML2 > would be just as good as QML1. Clearly something is causing that to not be > the case. > > What's the expectation when using video cards that don't offer OpenGL > hardware acceleration? > > -Todd > > > -Original Message- > > From: Storm-Olsen Marius (Nokia-MP/Austin) > > Sent: Saturday, January 14, 2012 9:12 AM > > To: development@qt-project.org; Rose Todd (Nokia-M/Alpharetta) > > Subject: Re: [Development] Status of QtDeclarative on Windows? > > > > Are you sure you are at least running the release version of your > application? > > > > Debug version uses the debug CRT libs (and a debug Qt which does the > > same), so everything will be a lot slower than the end product. > > > > You cannot really evaluate performance with debug builds. > > > > -- > > Sent from my Nokia N9 > > On 1/13/12 23:12 ext todd.r...@nokia.com wrote: > > Just for fun I’ve been playing with a medium-sized QML app that we had > > written for 4.7/Symbian and porting it to Qt5/QML2. Mostly have been > > working on Linux but the past few days I finally got around to > > compiling Qt5 on Windows and playing around with the project enough so > > that it would compile and run under qmlscene (it’s mostly qml/js with > > a C++ plugin module as well). > > > > Anyway, the performance on my Windows box is horrible. ListView > > scrolling, image loading, animations, everything is like it’s running > > in quicksand. Is this expected? If not, what do I need to do to in > > order to troubleshoot? This machine is relatively old and has a > > crappy video card (older Nvidia Quadro), but it should be more than > > good enough to run this app smoothly. Any tips or tricks to enable extra > debug tracing? > > > > Thanks, > > Todd > ___ > 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] Removing QBool?
2012/1/15 Giuseppe D'Angelo : > 2012/1/15 Gábor Lehel : >> 2012/1/7 Thiago Macieira : >>> On Saturday, 7 de January de 2012 01.03.50, David Faure wrote: Shouldn't we clean that up for Qt5 and just use a bool for the contains method again? The Qt4 API ensures that nobody still has if (contains()==2) in their code anyway. >>> >>> I think it should be gone. >>> >>> For the few methods where a boolean is needed and arithmetic is wrong, the >>> suggestion is to use the RestrictedBool solution: >>> >>> typedef int ClassName:: *RestrictedBool; >> >> Apologies for the off-topic: >> >> Is the RestrictedBool technique documented anywhere? What it does, how >> it works, why it works? I can see that it's using a member pointer to >> simulate a bool (presumably to avoid implicit casts to int and such), >> but not why this is preferable to a void* (fewer operations >> permitted?), and in particular why it has to be a pointer to a member >> of the specific class it is being used for instead of some >> globally-defined dummy class (even fewer operations permitted? but >> which ones?). Googling found nothing except the existing usage in >> QSharedPointer. > > See f.i. http://www.artima.com/cppsource/safebool.html Thanks! > > Cheers, > -- > Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On Sunday 15 Jan 2012 19:04:09 John Layt wrote: > I think I'm favouring the second option as being cleaner and easier to > implement in phases. After reading more of the ICU number API and trying some things out, I now think sticking closer to the current model will actually match the ICU API better and require less code albeit in one big bang. * QLocalePrivate holds instances of the ICU Locale, NumberFormat, DateFormat etc classes. QLocale methods call these objects directly to obtain format codes and perform format/parse without any call to QSystemLocale. * For Named locales, i.e. app creates QLocale instance for en_GB: QLocalePrivate is created, ICU Locale and format classes initialised. All QLocale calls will thus use only the CLDR default settings for the named locale. * For System locale, i.e. app creates default QLocale instance: QLocalePrivate created as per Named locales, but then calls QSystemLocale to obtain all the settings which are used to set the ICU NumberFormat and DateFormat default values. All QLocale calls will thus pickup the system settings. * A QCldrLocale is not really needed for Qt purposes, it's only needed for anyone who wants to know what individual settings are, like KDE. Note the ICU Format class instances may have delayed initialisation for efficiency, i.e. only when toString() is called for the first time. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On Sun, Jan 15, 2012 at 7:25 PM, Peter Kuemmel wrote: > > Off topic: > >> >> There would still be silent errors for people who have reimplemented >> the createRequest method (it's virtual). >> > > Technically interesting here is the question how such a > situation cloud be managed? Using C++11 'final' would > prevent the reimplementation. But using pre C++11, the only > idea I have is to define a dummy function with a different > return value, only this why the compiler would complain. One way would be to deliberately have a non-virtual method with the old name, then if you have the appropriate warnings turned on you'd get one for shadowing the existing method. I guess you might also be able to do something compiler specific to generate warnings in this situation (similar to the way deprecation attributes work). Cheers Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
Off topic: > > There would still be silent errors for people who have reimplemented > the createRequest method (it's virtual). > Technically interesting here is the question how such a situation cloud be managed? Using C++11 'final' would prevent the reimplementation. But using pre C++11, the only idea I have is to define a dummy function with a different return value, only this why the compiler would complain. Peter -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QLocale work
Hi, Apologies for an extended absence, life got rather busy. I've now pushed the first of my QDate changes for review, but the QLocale stuff now needs more focus as the next step. Discussions back in November around QLocale resulted in a decision to move to using ICU as the backend for all localisation functions, but left a lot of open questions which I'm now working on. The general philosophy seems to be: * The QDate, QTime, QDateTime, QString etc methods for toString/fromString should use C locale instead of System locale. These may use ICU routines or their existing routines, but this can be decided later. * QLocale will be the only class to localise values. All methods will be a thin wrapper around calls to ICU to perform the actual format/parse/whatever. * In order to respect users default locale settings, QLocale will still need to obtain settings from the host system and these settings or the CLDR defaults will be passed to ICU, rather than letting ICU decide on the required locale or settings. * The default host system locale settings will continue to be optional, if compiled out QLocale will use just the CLDR settings as currently, either by querying ICU or just calling ICU with the default locale. I think there's two different ways to do this within the current class model: * QCldrLocale - New class, returns the CLDR settings for a given locale. Initially could use existing CLDR settings code from QLocalePrivate and then later change to calling ICU. * QLocalePrivate - Could cache current locale settings from system or CLDR on creation to save repeated calls to System/ICU. If is system locale (i.e. not specific locale requested by app) then update on signal from host system that locale settings have changed. * QLocale - Reads settings from QLocalePrivate if cached, otherwise does a QSystemLocale and QCldrLocale query to obtain settings, and pass them to ICU routines. Alternatively: * QSystemLocale - Base class returns CLDR settings, derived system classes override with their settings where appropriate. Base class also provides the calls to ICU routines which derived class can override where needed. May or may not cache settings. * QLocale - thin wrapper that just passes all calls to QSystemLocale which works out what settings to use and calls to make. QLocalePrivate doesn't do much. * QT_NO_SYSTEMLOCALE - As QSystemLocale base class always needed, changes to mean to only use CLDR settings and ICU routines, and not host system settings or routines. I think I'm favouring the second option as being cleaner and easier to implement in phases. This gives a task list of: High priority, must be in 5.0 * Modify QLocale to use ICU per the decided model * Modify my existing Calendar code to use ICU instead * Modify QDate/QString/etc methods for toString/fromString to only use C locale instead of system locale with existing code. Lower priority, prefer done in 5.0 but can probably wait for 5.1: * Modify QSystemLocale sub-classes to return more platform settings (have existing patches) * Modify QDate/QString/etc methods to use ICU with C locale? Some other discussion points: * Date/Time format codes. The Qt4 format codes differ slightly from CLDR/ICU standard codes. Do we provide fallback support for the old codes, i.e. if QT4_COMPAT is set, or make a clean switch to only use the CLDR codes everywhere to save confusion? * Time Zones. This needs some serious work on what is needed in 5.0. I doubt we can have an agreed model, let alone code, by freeze date. * UNIX user settings - While I appreciate Thiago's argument that we need a single standard way for doing this on UNIX, that will be a way off and will not meet KDE's needs for a long time. With the switch to ICU, the first option is now to investigate if KDE can write a CLDR format locale file and force ICU to use that so Qt loads it that way. If that is not possible then a private QSystemLocale for KDE could be an interim option until a common standard is agreed, perhaps using Lars' binary json parser if it is in QtCore? Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing QBool?
2012/1/15 Gábor Lehel : > 2012/1/7 Thiago Macieira : >> On Saturday, 7 de January de 2012 01.03.50, David Faure wrote: >>> Shouldn't we clean that up for Qt5 and just use a bool for the contains >>> method again? The Qt4 API ensures that nobody still has if (contains()==2) >>> in their code anyway. >> >> I think it should be gone. >> >> For the few methods where a boolean is needed and arithmetic is wrong, the >> suggestion is to use the RestrictedBool solution: >> >> typedef int ClassName:: *RestrictedBool; > > Apologies for the off-topic: > > Is the RestrictedBool technique documented anywhere? What it does, how > it works, why it works? I can see that it's using a member pointer to > simulate a bool (presumably to avoid implicit casts to int and such), > but not why this is preferable to a void* (fewer operations > permitted?), and in particular why it has to be a pointer to a member > of the specific class it is being used for instead of some > globally-defined dummy class (even fewer operations permitted? but > which ones?). Googling found nothing except the existing usage in > QSharedPointer. See f.i. http://www.artima.com/cppsource/safebool.html Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On 1/15/12 5:08 PM, "ext Richard Moore" wrote: >On Sun, Jan 15, 2012 at 2:25 PM, Peter Kümmel wrote: >> But to think first about what "createRequest" really does is a good >>idea: >> It not only creates a request, it also sends it, so why not rename it to >> 'doRequest' or something similar which is different to 'createReply' >> which is as misleading as 'createRequest'. >> >> A new name would stop the compiler and there will be no silent bugs. >> And replacing a simple function name isn't that hard, so there is no >> need for a 'migration path' via deprecated functions. > >There would still be silent errors for people who have reimplemented >the createRequest method (it's virtual). I think this was covered >earlier in this thread. Yes, let's close it. All the maintainers and Approvers knowing QtNetwork seem to agree (and I actually do as well) to keep the name. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On Sun, Jan 15, 2012 at 2:25 PM, Peter Kümmel wrote: > But to think first about what "createRequest" really does is a good idea: > It not only creates a request, it also sends it, so why not rename it to > 'doRequest' or something similar which is different to 'createReply' > which is as misleading as 'createRequest'. > > A new name would stop the compiler and there will be no silent bugs. > And replacing a simple function name isn't that hard, so there is no > need for a 'migration path' via deprecated functions. There would still be silent errors for people who have reimplemented the createRequest method (it's virtual). I think this was covered earlier in this thread. Cheers Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing QBool?
2012/1/7 Thiago Macieira : > On Saturday, 7 de January de 2012 01.03.50, David Faure wrote: >> Shouldn't we clean that up for Qt5 and just use a bool for the contains >> method again? The Qt4 API ensures that nobody still has if (contains()==2) >> in their code anyway. > > I think it should be gone. > > For the few methods where a boolean is needed and arithmetic is wrong, the > suggestion is to use the RestrictedBool solution: > > typedef int ClassName:: *RestrictedBool; Apologies for the off-topic: Is the RestrictedBool technique documented anywhere? What it does, how it works, why it works? I can see that it's using a member pointer to simulate a bool (presumably to avoid implicit casts to int and such), but not why this is preferable to a void* (fewer operations permitted?), and in particular why it has to be a pointer to a member of the specific class it is being used for instead of some globally-defined dummy class (even fewer operations permitted? but which ones?). Googling found nothing except the existing usage in QSharedPointer. Thanks, ~g > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > Intel Sweden AB - Registration Number: 556189-6027 > Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On 13.01.2012 14:10, Mathias Hasselmann wrote: > Am Freitag, den 13.01.2012, 13:00 + schrieb Giuseppe D'Angelo: >> On 13 January 2012 12:32, Mathias Hasselmann wrote: what about the slightly more garden-variety approach of deprecating the old one and introducing a new method? >>> >>> Maybe we should check the premise of this discussion first. >>> Does that method really have the wrong name? It is called >>> "createRequest" and after all it causes creation of a network request. >>> Now this network request is just an internal object, and not exposed to >>> the API user. Instead the watchable reply object is returned in advance. >> >> The problem is that it doesn't match the Qt namings for the relevant >> classes... createRequest takes a QNetworkRequest (which is a >> "description" of the request that should be made), starts making the >> underlying network request as you described, but then also creates and >> returns a reply (QNetworkReply). Bikeshedding? > > Surely startRequest() would have been a better name. > But really not sure it is worth the hassle of changing it. > Still Robins suggestions shows a practical approach. > 'create' sounds like 'new', therefore QNetworkReply* r = x->createRequest(..); looks like int* i = new char; which is indeed strange. But to think first about what "createRequest" really does is a good idea: It not only creates a request, it also sends it, so why not rename it to 'doRequest' or something similar which is different to 'createReply' which is as misleading as 'createRequest'. A new name would stop the compiler and there will be no silent bugs. And replacing a simple function name isn't that hard, so there is no need for a 'migration path' via deprecated functions. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
