Re: [Development] Partial screen updates with Scenegraph
On Jul 19, 2012, at 2:23 PM, ext dietrich.gos...@conti-engineering.com wrote: Hi, Is it possible to set the new Grahpicsstack to do only partial screen updates? This would help me fixing some performance issues on embedded devices. Hi Dietrich, The scene graph does not do partial updates. Based on the experience we had from the widget stack and graphics view, we early on concluded that for applications which have moderate amount of animations, partial updates hurts a lot more than it gains. cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Friday July 20 2012, joao.abeca...@nokia.com wrote: Close to impossible. Oh, no. It's very possible. It's just not going to happen. We might as well have Qt50 and Qt52 and let the user pick one. Essentially, we're back at Qt5 and Qt6 with different names. Yes, with the difference that a Qt5 application can't link against a Qt6 Qt w/o recompilation. I'm not fighting for this, don't get me wrong, I'm just setting misconceptions straight. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Thursday 19 July 2012 14:19:36 Marc Mutz wrote: On Wednesday July 18 2012, Olivier Goffart wrote: We discussed namespaces long time ago already, and decided not to put Qt in a namespace. The reason is that it breaks source compatibility by breaking all the forward declarations. Even with inline namespaces? Then they would have failed to achieve their goal to hide the fact that the type is in an inline namespace. Yes, inline namespace won't help. If you do: class QString; int foo(const QString ); It creates the symbol _Z3fooRK7QString, which is different from _Z3fooRKN3v507QStringE. The suggested solution is, during Qt5 lifetime, introduce forward-declaration headers that declares all the Qt types, and deprecate the use of forward declarations. Then in Qt6 we can finally move in a namespace. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Partial screen updates with Scenegraph
On 07/20/2012 09:02 AM, gunnar.sle...@nokia.com wrote: Based on the experience we had from the widget stack and graphics view, we early on concluded that for applications which have moderate amount of animations, partial updates hurts a lot more than it gains. I already had several projects using Qt/Embedded where the framebuffer device was the performance bottleneck ( due to missing kernel support or an appropriate board support package ). Here partial updates were the only way to have an acceptable performance for certain operations like dragging objects over a canvas ! Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] cmake files for qt5 problems with Qt5Quick/Qt5Qml modules on Mac OS X
On Wednesday, July 04, 2012 16:54:54 Stephen Kelly wrote: On Monday, July 02, 2012 15:06:34 Stephen Kelly wrote: The headers that are not being copied during a developer build cause build errors like this: myheaderfile.h:4:31: error: QQuickImageProvider: No such file or directory Ok, can you post the full path of the Qt5QmlConfig.cmake you want to use, the full path of the Qt5CoreConfig.cmake you want to use, and the full path of the QQuickImageProvider you want to use? I'm trying to understand why the existing path is 'wrong'. Just FYI, I think the CI system hit the same bug as you: https://codereview.qt-project.org/#change,29241 The fix likely is going to be to copy the headers (along with the libs, cmake files, and everything else which is already there) to the qtbase location at build time if doing a developer-build, but we need to talk to mariusso about it. The required fixes have landed in the repo. Could you test again with unmodified cmake files? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | 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] QFileSystemWatcher and Recursive Monitoring
With FSEvents you cannot emit signals such as fileChanged(), fileModified(), pathCreated(), or pathDeleted() if all you're notified about is that something happened in this folder here, From my experience building an app that 'watches' a folder and imports all files of a certain type added there, I would prefer that QFSW was simple and reliable and doesn't attempt to impose a heavy cost or internal complexity (which translates into bugs) for things that the underlying APIs do not really support - leaving it up to the app to decide how best to handle these limitations. As you say, applications which are watching (possibly large) directory trees will likely have their own database of content which they will compare any changes to. The app can optimize this in domain-specfic ways, such as not recording any information about types of files it doesn't care about. Here is the FSEvents wrapper we use on Mac for example: https://gist.github.com/3149811 If the underlying APIs for fine-grained notifications and broad file system watches are quite different (as is the case for Mac), I think it makes sense not to try and 'paper over' that in the Qt APIs, so providing different classes would be better. Would be easiest to implement, we could even drop all the threading currently there now. There is a lot to be said for internal simplicity, especially where threading is concerned. Regards, Rob. On 20 July 2012 06:28, logic.cpp logic@gmail.com wrote: #1 Clarification of original post: When I say Making QFileSystemWatcher Recursive I mean *adding* new functions for recursive monitoring, such as addPathRecursively(). I don't mean to replace the current non-recursive functinality, which is very useful in its own right (for A category use cases mentioned). ___ 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] Partial screen updates with Scenegraph
2012/7/20 gunnar.sle...@nokia.com Is it possible to set the new Grahpicsstack to do only partial screen updates? This would help me fixing some performance issues on embedded devices.Hi Dietrich, The scene graph does not do partial updates. Based on the experience we had from the widget stack and graphics view, we early on concluded that for applications which have moderate amount of animations, partial updates hurts a lot more than it gains. Partial update support doesn't help for applications that don't _need_ it, rather. And high-end mobile phones where there's enough CPU and GPU power for the UI, which is the focus of QML 2 and the SceneGraph, don't need it. For hardware and applications where memory bandwidth and CPU/GPU power is an issue, for example when resolutions go above 800x480 (e.g., retina) and there are multiple screens, with multiple layers (e.g. video playback or animated wallpapers), supporting partial updates becomes a matter of win or lose. Wasn't EGL_NOK_swap_region2 added for this reason? Since SceneGraph doesn't support partial updates, those who need that should choose QML 1 with QGV [*]. Perhaps when QML 3 comes out, there's be a single solution to both problems ;-P. [*] In QGV you can select QGraphicsView::FullViewportUpdate to avoid the cost; the default being QGraphicsView::MinimalViewportUpdate which supports disjoint viewport updates. QGraphicsView::BoundingRectViewportUpdate is a good go-between. The cost imposed is not that bad. The example of dragging an object around a screen without imposing full updates and complete redraws is logical. -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Partial screen updates with Scenegraph
On 07/20/2012 12:32 PM, Andreas Aardal Hanssen wrote: Partial update support doesn't help for applications that don't _need_ it, rather. And high-end mobile phones where there's enough CPU and GPU power for the UI, which is the focus of QML 2 and the SceneGraph, don't need it. What about using regular desktop applications remotely ( X11, NX, VNC ... ), where the network bandwidth is a limiting factor. F.e. in home office environments you sometimes run UIs over DSL ( or even slower ). Isn't QML 2 the recommended API for desktop applications too ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] To admins: QtSerialPort, need remove unused branch 2.0 from Gerrit
Hello guys. For add-on QtSerialPort in the playground need to remove the branch 2.0. This branch (from parent QSerialDevice library) was mistakenly left in after the process of porting add-on to Gerrit. I do not have enough privileges to do so. Who are some of the admins can help me? Best regards, Denis ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Partial screen updates with Scenegraph
2012/7/20 Uwe Rathmann uwe.rathm...@tigertal.de On 07/20/2012 12:32 PM, Andreas Aardal Hanssen wrote: Partial update support doesn't help for applications that don't _need_ it, rather. And high-end mobile phones where there's enough CPU and GPU power for the UI, which is the focus of QML 2 and the SceneGraph, don't need it. What about using regular desktop applications remotely ( X11, NX, VNC ... ), where the network bandwidth is a limiting factor. F.e. in home office environments you sometimes run UIs over DSL ( or even slower ). Isn't QML 2 the recommended API for desktop applications too ? I think it's really important for any desktop GUI to allow efficient desktop sharing like that. But good sharing technologies don't rely on partial update support in each and every application. Generally speaking, applications based on transferring graphical content over the network like that are split into two parks: (1) Those who rely on expose events from the gui app to optimize traffic and (2) those who use proper video encoders / that send compressed delta updates by comparing frames. The latter supports everything, the former is, IMO, really inefficient and should be a thing of the past. I think partial update support is really about the local device's capabilities. -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] To admins: QtSerialPort, need remove unused branch 2.0 from Gerrit
On 07/20/2012 01:40 PM, ext Denis Shienkov wrote: Hello guys. For add-on QtSerialPort in the playground need to remove the branch 2.0. This branch (from parent QSerialDevice library) was mistakenly left in after the process of porting add-on to Gerrit. I do not have enough privileges to do so. Who are some of the admins can help me? Best regards, Denis done -- Sergio Ahumada ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion on QML portability
On Wednesday 18 July 2012 07:26:55 gunnar.sle...@nokia.com wrote: On Jul 17, 2012, at 9:17 PM, ext Andreas Aardal Hanssen wrote: 2012/7/17 marius.storm-ol...@nokia.com (2D accelerators are often bundled with GPUs and perform 2D rendering ops faster than GPUs, but are unusable with QML 2 / SceneGraph; see pvr2d). 2D accelerators bundled with GPUs perform 2D rendering ops faster than GPUs? Uhmm... that sentence is conflicting in my head, unless you mean that you are using highly specialized boards with multiple GPUs (n*PVR) on them to do things really really fast in parallel. [OT] No, I really mean dedicated 2D hardware chips outperform GPUs by far. It's easy to do certain common simple 2D graphics faster than most embedded GPUs I know of, even using the CPU. GPUs are built for (1) 3D transformations on textures, (2) vertex-heavy objects and (3) per-pixel shading operations. But it's easily beat for simple 2D operations like blit (e.g., DMA), filtering/scaling (e.g., FPGAs). Most mobiles / tablet UIs are 90% 2D. My point is simply that Qt 5 is best served with a painting backend for QML 2 that can support non-OpenGL technologies. Though true that 2D blitters support the basic features needed by many UI's it also comes with a lot of limitations. They often operate on contiguous memory blocks, which need to be allocated by the kernel and comes which is limited in terms of what you can allocate. On several chips I've worked on, this is a system-wide pool, specified at boot-time. They would also not support basic primitives, such as drawing rounded rectangles, antialiasing, free rotation, perspective transformation and 9-patch border images. So all of these would have to be rendered in software. This means a heavy mixing of CPU and accelerated drawing and we both know that combination does indeed suck. OpenGL is flexible enough to support what we need while at the same time providing us with very good performance, so it is the best thing we got. If you know you are not using any of these features, then you could write your own renderer using the scene graph adaptation layer. A renderer that only looks at translate and scale transforms, maybe supports opacity and draws solid color boxes and pre-generated images. Text could be done using the adaptation for glyph nodes to render text using QPainter and then that could also be blitted in the renderer. This is doable today, but it would not support the full QML feature set, so it is not something we will invest time in. There is also the possibility of using a software emulation library for the OpenGL stack to do all the rasterization in software, if there is no OpenGL chip. QML2 on llvmpipe beats QML1 on QPainter/raster, after all.. In my experience your statement is not true. With llvmpipe I could run some ~400x300 pixel QML2 demos(*) at 60 FPS on a 2.4 GHz Core 2 CPU with maybe 40% load. I have also seen a ~480x320 pixel QML1 UI I worked on run at 20 FPS on a 300 MHz ARM9 CPU. The desktop CPU is at least 15x faster. The ratio of instructions per pixel and frame is then, approximately: 15 * 0.4 * (480 * 320 * 20) / (400 * 300 * 60) = 2.56 which is very good for the hard task llvmpipe is accomplisihing, but nevertheless it is slower. (*) with surprisingly little frame rate and CPU load difference between the simplest Pong demo and some advanced ones using pixel shaders - I made sure that I was really using the software renderer, and I was, because the CPU load went to 10% after switching to hardware OpenGL. Cheers, Andreas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFileSystemWatcher and Recursive Monitoring
I would prefer that QFSW was simple and reliable and doesn't attempt to impose a heavy cost or internal complexity (which translates into bugs) for things that the underlying APIs do not really support Same opinion here. Since we could get a good solution for windows only, the QRecursiveFileSystemWatcher class goes to be not really cross-platform. Where the amount of nested levels is relatively small, the QFileSystemWatcher could be used for recursive watching manually instead - in a cross-platform way. P.S. I'm still interested in improving the QFSW windows backend by using ReadDirectoryChanges WinAPI instead of thread pool of waiters/listeners. regards, Konstantin 2012/7/20 Robert Knight robertkni...@gmail.com: With FSEvents you cannot emit signals such as fileChanged(), fileModified(), pathCreated(), or pathDeleted() if all you're notified about is that something happened in this folder here, From my experience building an app that 'watches' a folder and imports all files of a certain type added there, I would prefer that QFSW was simple and reliable and doesn't attempt to impose a heavy cost or internal complexity (which translates into bugs) for things that the underlying APIs do not really support - leaving it up to the app to decide how best to handle these limitations. As you say, applications which are watching (possibly large) directory trees will likely have their own database of content which they will compare any changes to. The app can optimize this in domain-specfic ways, such as not recording any information about types of files it doesn't care about. Here is the FSEvents wrapper we use on Mac for example: https://gist.github.com/3149811 If the underlying APIs for fine-grained notifications and broad file system watches are quite different (as is the case for Mac), I think it makes sense not to try and 'paper over' that in the Qt APIs, so providing different classes would be better. Would be easiest to implement, we could even drop all the threading currently there now. There is a lot to be said for internal simplicity, especially where threading is concerned. Regards, Rob. On 20 July 2012 06:28, logic.cpp logic@gmail.com wrote: #1 Clarification of original post: When I say Making QFileSystemWatcher Recursive I mean *adding* new functions for recursive monitoring, such as addPathRecursively(). I don't mean to replace the current non-recursive functinality, which is very useful in its own right (for A category use cases mentioned). ___ 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] Native event filter
On Tuesday 26 June 2012 13:17:27 Thomas McGuire wrote: Hi, On Tuesday 26 June 2012 12:48:56 David Faure wrote: So I looked further into this, and discussed it with several people at QtCS, and decided that not only the implementation needed fixing, the API too. The current API can lead to crashes if removing install event filters in a different order than the reverse-order-of-setting, and leads to ugly code (global C function, which basically requires having a singleton). In https://codereview.qt-project.org/#change,29260 I'm proposing a new API: QCoreApplication::instance()-installNativeEventFilter(obj); I very much support this change and hope it will get into Qt 5.0. Currently the system is very brittle once you try to install more than one EventFilter, as the filters are chained, and the user of the API needs to remember to call the previous filter in the chain, or everything breaks. In addition, if one of the filters in the chain gets deleted, there are dangling pointers and again the whole chain is broken. Yet using EventFilters is unavoidable, for example the Blackberry QtMultimedia backend needs it to get multimedia update events. As this API solves all this, I'd really like to see that in Qt. It's in, finally :-) -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] To admins: QtSerialPort, need remove unused branch 2.0 from Gerrit
thank you Best regards, Denis On 07/20/2012 01:40 PM, ext Denis Shienkov wrote: Hello guys. For add-on QtSerialPort in the playground need to remove the branch 2.0. This branch (from parent QSerialDevice library) was mistakenly left in after the process of porting add-on to Gerrit. I do not have enough privileges to do so. Who are some of the admins can help me? Best regards, Denis done -- Sergio Ahumada ___ 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] QFileSystemWatcher and Recursive Monitoring
snip, please share thoughts on QFileSystemWatcher (maybe monitor-recursive) As you say, applications which are watching (possibly large) directory trees will likely have their own database of content which they will compare any changes to. The app can optimize this in domain-specfic ways, such as not recording any information about types of files it doesn't care about. I'd like to kind-of-disagree here: IDEs like QtCreator or any-other-developer-IDE would need to monitor large directory trees, and may not rely upon their own databases. It would be nice to have this recursive-monitoring for things like build-system-daemons. The goal is central-notification-from-many-large-file-system-roots, and that seems like a fairly useful abstraction that could be used by many application-specific tools. Really good work, IMHO, comparing about the cross-platform issues. Bummer about the Mac. It would be curious if that were to change going-forward (as the future is larger hard drives, and more reliance upon files as everybody goes SSD-fast). I'd *prefer* a QFileSystemWatcherRecursive implementation, even if it could not be cross-platform (e.g., problems on the Mac). I understand why that's not preferred -- we want to get away from system-specific anomaly. Mostly, I'd hope that over time, there would be a technical solution to get it working on the Mac, but at least let people could start using it on Windows/Linux. I could be talked out of this, though. Just my $0.02. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Could anyone provide the mkspec for Windows clang tool chain?
Hi list, I want to use clang compiler with MinGW tool chain on my Windows box, does any one have the mkspec for Qt 4.8.2? Thanks in advance. -- Regards, Fan Yang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
