Re: [Development] Changes to QObject::connect and other functor-taking API implementations
Hi all, > What started as an attempt to provide a few building blocks for making > it easier to build asynchronous APIs taking any kind of callable (like > QTimer::singleShot ... Sorry for posting without checking your implemented solution: one of the goals of my QSkinny ( https://github.com/uwerat/qskinny ) project is to allow more lightweight Qt/Quick applications. And one detail is about not having to create QObjects for simple callback situations. It is quite some time ago ( ~2017 ), that I made that implementation but IIRC the main challenge was about identifying the callback parameters using meta template programming instead of having them from the signal signature. The rest is more or less given by the design of QtPrivate::QSlotObjectBase It does not make the definition of functor callback APIs a no-brainer - but IMHO it is much better than what you would have to do without. See: https://github.com/uwerat/qskinny/blob/master/src/common/QskMetaFunction.h The implementation is heavily used for processing machine data in a commercial project ( avoiding >1K of QObjects ). Unfortunately I can't show it here - but there is at least one example how to build an API with it in QSkinny itself: https://github.com/uwerat/qskinny/blob/master/src/controls/QskShortcutMap.h https://github.com/uwerat/qskinny/blob/master/support/SkinnyShortcut.cpp There is a small demo/test program available that does a bit more with this all: https://github.com/uwerat/qskinny/tree/master/playground/invoker In case you find something of interest in my implementation: QSkinny code is BSD-3-Clause. ciao, Uwe -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt/Quick and VNC
On 6/4/22 23:20, Giuseppe D'Angelo via Development wrote: I'd tend to agree; for some of our customers we indeed used H.264 encoding using VDPAU/VAAPI. Actually H.264 covers the idea of sending differences between 2 frames only - but without requiring any support of Qt/Quick. However you will have a hard time finding a VNC viewer supporting H.264. IIRC xtigervnc added it very recently - never heard about any other viewer doing the same so far ( that's why I started with JPEG ) But in most VNC scenarios the user only needs to have one combination that works and when the device running the Qt/Quick application has VDPAU/VAAPI support then having the H.264 option IMHO offers the best solution possible. However, for lower end embedded platforms lacking HW video encoders (but still with a GPU), we had to do CPU encoding of the changes and having damage areas helps tremendously. Results depend on the device, the size of the frames and its content ( being more quiet equals to better compression ) - but at least these are some numbers from one of my test setups: - Intel NUC with on board GPU - window of 800x800 pixels - a couple of indeterminated progress bars ( using qskinny ): xtigervnc reports: - using raw encoding: ~2fps - using Tight/JPEG: ~20fp I would argue, that image compression offers a "working" solution, while knowing the update regions only is an improvement, but remains on the "non working" side for modern UIs. But of course the RFB protocol supports both type of optimizations and in case the update region is known a VNC server should only send them. Concerning the image compression: In the beginning the viewer sends all encodings ( https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#encodings ) it supports to the server. Then the server makes its decision how to send the image data for the dirty rectangles ( might be even possible to use different encodings for each rect ). However the VNC server that is implemented in the VNC platform plugin completely ignores the requests/capabilities from the viewer and supports the mandatory Raw format ( https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#raw-encoding ) only. IMHO this is simply not good enough to achieve satisfying results for modern UIs. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt/Quick and VNC [ was: damage tracking ... ]
Hi all, sorry for hijacking a thread in a slightly different direction, but as I was working on a VNC solution for Qt/Quick for EGLFS recently. My VNC server ( BSD-3-Clause license ) can be found here: https://github.com/uwerat/vnc-eglfs The main reason why I'm not happy with the official VNC plugin is that it does not support any type of OpenGL. Beside the known limitations of the software backend this means that custom scene graph nodes usually do not work at all. My customer also needed a solution, where the application is displayed locally and remotely at the same time. [ Giuseppe D'Angelo wrote: ] Properly signalling damage areas has a lot of interesting use cases, from compositors to efficiently enable remoting solutions (frame streaming/VNC/etc.). Well, Qt/Quick is usually for modern user interfaces with smooth state transitions, what means you have to deal with a lot of fullscreen operations like fading in/out of pages etc. that have to run at 60fps. While limiting update regions to the damage areas is of course often an improvement - it is is no game changer as you also have the use cases above. IMHO the solution to the problem can only be: using image compression formats like JPEG or even better H.264. The current state of my VNC server implementation supports JPEG using the encoder ( libjpeg-turbo ) that comes with Qt. But even with having an expensive glReadPixels call and JPEG compression for each frame I was able to display ~20fps remotely for a 1200x800 window. ( numbers reported from xtigervncviewer -Log '*:stderr:100' ) Unfortunately I didn't have enough time for the project and was not able to get the libva running. This should avoid the bottlenecks above by encoding on the GPU before downloading the compressed frame. ( Will try to do it at a later point in time) If someone is more familiar with the VA_API and is interested in my approach - please let me know ? A comment on the VNC platfom plugin that comes with Qt: the approach that has been taken has its pros ( also works for widgets ) and cons ( see above ). But I noticed that there are a couple of features that are missing that could be added easily: - more Encodings ( f.e JPEG ) - Mouse wheel support ( see my code ) - more key codes ... Looks a bit like the code had been adapted from 15 years old QWS code without checking what has happened in the mean time: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst cu, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6.2 QQmlMetaType incompatibility
Servus Ulf,
What part of the docs do you mean here?
https://doc.qt.io/qt-6/qqmlengine.html#QML_ANONYMOUS
"Declares the enclosing type to be available, but anonymous in QML.
The type cannot be created or used as property type, but when passed
from C++, it is recognized."
Thought that "property type" is supposed to be the type of a property
being exposed to QML ?
I can file a bug report if you agree, that the docs are wrong - or at least
misleading ?
You can very well have anonymous value types as C++-declared > properties of other types. It may be that we're still missing some >
bits and pieces for the creation from JS values to work. So far the >
approach is only used by the QtQuick value types. Some of those are >
indeed anonymous, but all of them happen to use the foreign/extended >
hack. It should also work without that hack, though. Feel free to > open
a bug report or submit a patch.
As QML_ANONYMOUS is only a macro for "Q_CLASSINFO("QML.Element",
"anonymous")"
I was trying to identify, where "QML.Element" gets processed and didn't
find something
beside code of the qmltyperegistrar tool.
I also read your additional reply as qmltyperegistrar being mandatory
for my use case.
As my QSkinny project is currently used in pure C++ projects only I have
to confess,
that I did not pay enough attention to the QML aspects and static type
registration
( https://www.qt.io/blog/qml-type-registration-in-qt-5.15 ) should of
course be the way to go.
Will do my homework.
Thanks,
Uwe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6.2 QQmlMetaType incompatibility
Hi Ulf,
thanks for the hints.
instead of using QQmlMetaType::registerCustomStringConverter() you > can add a static create() function that takes a QJSValue as argument
> to your class or have a ctor that takes QJSValue. Then register the >
type using QML_ANONYMOUS and it should be possible to create it from >
any JavaScript value assigned to it.
Couldn't get something running with this approach.
But as I'm using my class as property and the docs state that this
is not possible with classes being declared as QML_ANONYMOUS I gave up.
You can also do a number of interesting and nasty things to wrap the > existing QMarginsF into a value type. Take a look at >
qquickvaluetypes_p.h in qtdeclarative for "inspiration". > > The only
thing shown there that you cannot do to your own value > types is giving
them names. The names passed to QML_VALUE_TYPE() are > only decoration
so far because the actual name resolution for value > types is still
hardcoded.
Not sure if I 100% understood this concept. Isn't it more about
declaring something in QML than using C++ classes from QML ?
Being able to provide a static create function would indeed be a good
solution:
QVariant QskMargins::create( const QJSValue )
{
if ( ... )
{
const auto m = params.toNumber();
return QVariant::fromValue( QskMargins( m ) );
}
...
}
But how to tell the engine to make use of it when executing a property
assignment ?
With Qt < 6.2 it was as simple as that:
QQmlMetaType::registerCustomStringConverter( qMetaTypeId< QskMargins
>(),
[]( const QString& s ) { return QVariant::fromValue(
QskMargins( s.toDouble() ) );
Maybe it is possible to reintroduce something similar ?
Thanks,
Uwe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Qt 6.2 QQmlMetaType incompatibility
Hi,
when testing the Qt 6.2 rc I noticed that registering custom string
converters with
QQmlMetaType::registerCustomStringConverter() has been dropped.
( Yes, QQmlMetaType is from the private API where no compatibility
policies are made )
Actually I'm not interested in having a custom string converters - I was
using it as a workaround
to be able to create a margin that is made from 4 values ( left, top,
right, bottom ) from a single
value in QML.
Instead of writing:
Box
{
margins
{
left: 10
top : 10
right : 10
bottom: 10
}
}
I would like to have the option to write it that way:
Box
{
margins : 10
}
}
Here is my solution - one I do not like much - but it worked until Qt 6.2:
For some reason neither the Qt metatype system nor the QML engine has
specific support for
QMarginsF - like what is implemented for classes other standard Qt types
like QPointF/QRectF/QSizeF ...
So I derived from QMarginsF and exposed it to QML using Q_GADGET.
See https://github.com/uwerat/qskinny/blob/master/src/common/QskMargins.h
To make the single value assignment possible I added the following:
QQmlMetaType::registerCustomStringConverter( qMetaTypeId<
QskMargins >(),
[]( const QString& s ) { return QVariant::fromValue(
QskMargins( s.toDouble() ) ); } );
Is the a way to accomplish something similar with Qt 6.2 ?
Thanks,
Uwe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
On 12/5/19 6:12 PM, Giuseppe D'Angelo via Development wrote:
In this light, what's the idea of a global minimum size useful for?
It is/was useful for widget applications running on devices with touch
screens, where the default metrics from the styles are too small.
You could argue that a good style API allows to increase all sizes by
overloading the virtual methods, but this is very tedious and I doubt,
that you can do everything this way.
And of course you won't be able to handle 3rd party widgets that QStyle
does not know of. F.e for Qwt widgets only globalStrut is effective.
Proper sizeHint implementations have to look like this:
QSize QwtWheel::sizeHint() const
{
const QSize hint = ...;
return hint.expandedTo( QApplication::globalStrut() );
}
Uwe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
Hi Shawn, FWIW I did try to make that point during the session, since you weren’t there to do it yourself, that you would like to have something like a table of QVariants instead of only colors (to include things like icons and border line widths and radii), and also that the ColorRole enum should be extensible or replaced with something that is extensible (such as a string). When looking at the current implementation you have a combination of attributes coming from the widgets ( colors, fonts, ... ) and from QStyle ( metrics like QStyle::PixelMetric, ... ). Then you have some code that is located inside of the style, that is responsible for layouting and rendering the subcontrols from these attributes. Whether these attributes are stored in a table as QVariant or somehow else is a detail of the implementation - the issue I'm interested in is a system that allows me to extend/replace the number of attributes and the layout/rendering code in a more flexible way. Another aspect I'm missing is how to define transitions between states in an easier way. So I would like to have a system that allows me to set state depending attributes and some definitions for the state transitions ( f.e QEasingCurve::Type + duration ), so that the style can manage the transitions automatically by interpolating between the attributes. a) The system I have implemented in QSkinny splits the layout/rendering code into different classes. Those are called skinlets - what might translate to controlDelegate in the usual Qt terminology. f.e the following code registers/replaces a skinlet for a custom control: skin.declareSkinlet< MyControl, MyControlSkinlet >(); Then you can add whatever attributes are used by MyControlSkinlet and you are done. Such a system allows to replace/expand/remove the number of controls being supported by a style in a much easier way than with the monolithic approach you have in QStyle. b) Then I indeed have a table of attributes with colors/metrics/flags + attributes for the transitions. The basic idea behind separating the attributes from the delegates is that setting attribute values is something a GUI designer can do while creating scene graph nodes ( this is what the skinlets do ) is definitely a job for an experienced developer. I was thinking it would be a good start to add a high-numeric-value QPalette::ColorRole::UserRole and then you could extend that with your own enum for use in your own widgets and styles. Please allow me to add fonts here as well. All projects I have been part of in the last decade had a concept of using font roles. You have a preference dialog where the user can assign specific fonts to given roles, like f.e Title/Body/... So I would also raise the question if the inheritance model that is used for fonts in widgets and QC2 still matches the reality of the applications. But what to do instead then? More work is being done already at this time to get QPalette working better in Qt Quick, but maybe we should replace it with something else entirely? With Qt6 we will see fundamental changes in the scene graph and below and a new QML version. So the controls are actually the only layer of the Qt/Quick stack, that is not under heavy reconstruction. The question is how much changes you are willing to do. IMHO it would be time to move on with the controls too - but can this be done without major API changes ? So in the logic of being sensitive with breaking APIs this can only be done as Quick Controls 3. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
On 12/4/19 4:07 PM, Volker Hilsheimer wrote: That’s cool! Sadly, many of our widgets (for instance, none of the item views), and none of our quick controls respect the globalStrut property. QApplication is about widgets, while Qt/Quick is usually QGuiApplication and should be no argument here. Adjusting the itemViews to respect the globalStrut should be no big deal - IIRC I did this once by overloading QItemDelegate::sizeHint. Application UIs are anyway designed for touch if they are for devices; trying to make desktop UI concepts and widget sets work for touch UIs is fortunately a thing of the past. I agree, that not many projects will start on embedded devices with Qt/Widgets nowadays - the only motivation I can imagine might be avoiding QML. But there is a lot of legacy code and migrating it to a more recent version of Qt is not the past. F.e our previous generation of terminals is done by tweaking the windows style and is also using globalStrut. Without it things would be harder - probably not possible without patching the implementation of the windows style. So, even if it were done more thoroughly, I think a toolkit-specific “strut configuration” is no longer a sensible approach. Unfortunately the session about styles at the QtCS ( https://wiki.qt.io/Qt_Contributors_Summit_2019_Program#Future_of_QStyle_for_widgets_and_controls ) had been moved to a time slot where I had already left. One thing I had planned to mention is that I consider the whole styling concept you have in Qt today as a thing of the past for embedded UIs. All user interfaces I have worked on in the recent years consist to 30-50% of custom controls - and the requirement of being able to style them is beyond the concept of QStyle and friends. F.e think about QPalette - what is even used for QC2. This might have been good enough for desktop applications and its limited set of widgets, but not for the variety of fancy controls you find on embedded UIs. But the problem of how to make 3rd party controls "stylable" goes back to the very beginning of QStyle - I never had a solution for my Qwt widgets. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On 11/26/19 12:35 PM, Olivier Goffart wrote: "QML Strict is as subset of QML which is more maintainable and performs better" Isn't it that way: QML is for convenience but expensive. C++ is often less convenient but with better performance and lower memory footprint. QML Strict is a compromise - something in between. Then people can make a conscious decision, what is the right choice for their situation. IMHO being honest about what is what makes more sense, than how it was f.e. done with QC2. That was sold as something specific for embedded but actually it was about replacing QML by C++ code to get around performance issues. My 2 cents, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
On 11/23/19 11:26 PM, Thiago Macieira wrote: Wrapping int() around requires more manual work. I understand, but I think this is the type of change that will eventually become a problem down the road. We think it can help with porting, but it may later introduce subtle bugs by truncating sizes. Something that is very common in application code is, that you have some sort of index, where -1 is used to indicate that the index is not valid, f.e QVector::indexOf Statements where you compare an index with the size happen often and when they don't have the same data type it is not a temporary migration problem - it is a regression in terms of convenience. I fully agree with André - having 2 different APIs makes a lot of sense to me. But instead of using count/size I would use something like countU/sizeU. like you have QPen::widthF and QPen::width. My 2 cents, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from the Qt 6 Changes / Migration session
On 11/22/19 11:01 AM, Friedemann Kleint wrote: https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_6_Changes_/_Migration Maybe one aspect I would like to add: there is a lot of software, that has to be compilable with Qt 5 and Qt 6. Especially when your product is library you can't decide which version of Qt is going to be used in the application. It would be good if this does not end up in a total mess of ifdefs. My experience from the past is, that it takes years until the majority of the applications has upgraded to the next major Qt version - and probably only few applications will seriously try out Qt x.0 versions. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Contributor Summit 2019 sessions
On 11/8/19 9:51 AM, Richard Weickelt wrote: doing scene graph node composition ? > What is the latter? It is mostly about having a lower memory footprint. a) With QML you only have access to ~heavy objects like QQuickItem and the controls are usually compositions of basic items like text/image/rectangle. F.e a page indicator with n bullets from QC2 is made of n + 3 QQuickItems. Each item has an impact on the scene graph as it adds at least an additional transform node. Each bullet is a QQuickRectangle, that has a gradient made of stops. Each gradient and each stop of each rectangle is a QObject. I leave it up you to sum things up: sizeof( QSGNode ): 80 sizeof( QSGTransformNode ): 216 sizeof( QObjectPrivate ): 112 sizeof( QObject ): 16 sizeof( QQuickItemPrivate ): 320 sizeof( QQuickItem ) : 32 The page indicator of QSkinny is exactly 1 QQuickitem that creates exactly one node per bullet. The same technique is used for almost all QSkinny controls - f.e a push button is made of Panel/Image/Text nodes. The maybe most extreme example is the listbox that is also one QQuickItem only. b) Having access to the nodes also allows a more memory aware approach about when to create/destroy nodes. The application driving QSkinny is a beast of ~250K lines of code, having ~2000 different images. For applications like these you simply have to be careful about resources. I'm not sure if that is what You have in mind, but I think that QML's language features: No, I don't want to make a statement about QML vs. C++. This is something that needs to be decided based on the situation of a project and the preferences of the development team. But of course you need to do C++ when accessing the scene graph or its nodes. ciao, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Contributor Summit 2019 sessions
Hi all, thanks a lot for allowing me to join the QtC Summit this year. I'm wondering if anyone is interested in my experiences with using the Qt/Quick technology in a non standard way. I was specifically thinking of the QSkinny theming system and the implications of doing scene graph node composition ? ciao, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Property bindings in Qt 6
On 10/2/19 5:19 PM, Pierre-Yves Siret wrote: While using layouts in the Qt Quick world, you use Layout attached properties to give hints to the layout system : Sure it is a subset of the options you have with the corresponding layouts of the widgets world. It is possible to set the explicit min/preferred/max hints, but of course the implicit hints can't be done this way. And as dynamic constraints ( heightForWidth/widthForHeight ) are always implicit, these layouts do not support them. In case anyone is interested: I wrote a small demo ( https://github.com/uwerat/qskinny/tree/master/playground/grids ) that shows side by side, what the different grid layout implementations are doing, when being fed with same attributes. It is interesting how many obvious differences/bugs you find - even in QGridLayout, that has a history of > 15 years. I decided not to write bug reports ( explanations are in the code ), as I don't expect anyone fixing them. The QGraphicsWidget stuff has become obsolete ( why is this not already deprecated ? ) and probably nobody wants to touch the widgets layouts - even if it is actually a bug fix. Qt/Quick layouts are only a thin layer on top of the graphics view layout engine and could be reimplemented from scratch in 2-3 days - in case someone wants to do it. I don't understand/visualize what you mean. Classic layouting usually means stacking of box/grid layouts. Each box makes use of the information of the child boxes - actually child boxes are not different than basic controls. So it is important, that each box offers the same min/pref/max hints to its parent box - and of course these values should be calculated automatically. F.e when having a horizontal linear layout, the preferred width of the layout can easily calculated by adding the preferred widths of the children. The graphics view layout system is the most complete implementation. F.e have a look at: https://doc.qt.io/qt-5/qgraphicslayoutitem.html#sizeHint This method does not only calculates the accumulated pref/min/max values it can also be fed with a constraint: when one of its width/height is >= 0 a heightForWidth/widthForHeight calculation is performed. So whenever you have to do layout calculations you can rely on having these information from your children. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Property bindings in Qt 6
On 10/2/19 4:36 PM, Jason H wrote: There is fontSizeMode: Text.Fit, .HorizontalFit and .VerticalFit. Horizontal fit is what you want in that situation. But the whole implementation is lacking because you can't actually ask the Text what size it used to render so that other text items on the screen can be the same size. Typical layout classes have 2 things to do: a) calculating the geometry of the children b) offering layout information to the parent calculated from the information provided by the children. With Widgets, GraphicsView or my framework the system depends on the min/preferred/max hints being evaluated by a size policy. F.e QSizePolicy::hasHeightForWidth() tells the layout classes, what to do. QQuickItem has the implicitSize ( = implicit preferred size ) only - no other explicit/implicit size hints and no policy. And b) has become something you have to implement manually on application side. With anchoring things are even worse: there is not even a container who is in control of the scenario, that could do the job. Ironically GridLayout/RowLayout/ColumnLayout are using the same layout engine as the layout classes of the QGraphicsView framework. It offers all the whistles and bells, but QQuickItem does not have the parameters to feed it. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Property bindings in Qt 6
Hi Chris, should individual items have to know/track this ... Well, anchoring is also based on size changes, but uses a different type of notification -> item change listeners. Not sure why the authors decided to introduce yet another type of notification - instead of using event + event filtering - but it is obvious, that the way how property bindings are processed is irrelevant, when not being involved. Maybe a side note on anchoring: with AutoLayout ( IOS ) and ConstraintLayout ( Android ) there seems to be a trend to Cassowary ( http://overconstrained.io ) based layouts for declarative systems. QGraphicsAnchorLayout is also based on the Simplex algo, while Qt/Quick anchoring with its property-pingpong approach - well, judge yourself. Maybe I'm misunderstanding again, but that's what the binding is supposed to implement (a change to a dependency marks the binding as dirty but doesn't trigger its evaluation until the property which owns the binding is accessed, at which point the binding is evaluated). Technically it is possible to do a lazy calculation of the implicit size by overloading QQuickItemPrivate::getImplicitWidth/Height. But this is only used by Text/TextInput/TextEdit and is not part of the public API. Not to mention, that QML code will never be able to make use of it. Also the implicit size of longish texts is usually irrelevant as in most situations the layout needs a height-for-width value. IIRC Qt/Quick does not even has a concept for how to deal with this type of constraints. Furthermore: layout calculations have to be done in top down order - the container needs to have its final geometry first. With my approach of doing things in updatePolish it means, that the to-be-polished list has to be ordered and to do so items need know their item-tree depth to allow fast insertions. Stuff like this is what IMHO needs to be done to substantially improve the layout system of Qt/Quick and the maintainers of Qt/Quick Core and Controls need to become active. Kudos to all these micro optimizations in the runtime environment, but they can't compensate systemic design problems. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Property bindings in Qt 6
On 9/28/19 8:49 AM, Simon Hausmann wrote: Instead of an idle timer, all imperative triggered onFooChange handlers are queued up and called right before the next frame. Property binding is not the only notification mechanism and if its synchronous character is not appropriate for a specific situation, the correct solution could also be to use a different type of notification. F.e. the Qt/Quick layout system is based on binding the implicitSize while QWidgets or QSkinny indicate layout relevant changes by sending a QEvent::LayoutRequest to the parent. In the specific situation of Qt/Quick you know, that you don't need to do any layout recalculation before the next frame and as the documentation of QQuickItem::updatePolish states - "This function should perform any layout as required for this item." - it is an obvious implementation to simply call polish + posting a LayoutRequest, when receiving a LayoutRequest. So in general everything is prepared to do it in an efficient way, only the Qt/Quick controls/positioners/layouts don't do the obvious. Using a different type of property binding instead does not fix the actual design flaw: indicating that the implicit size has changed does not require calculating it in advance ! I guess the majority of the problems you want to solve with delaying the execution of property bindings are related to layout recalculations and once those are gone you don't have to change the synchronous character of property bindings anymore. Beside that it is a questionable assumption, that all property bindings are related to the next frame and that processing the bindings right before the next frame is the right point in time. It might delay bindings that should be done earlier, but also hurt the frame rate as entering the scene graph thread might be blocked by calculations, that should better have been in between frame updates, where the CPU was idle. On a general note: IMHO you ( = Qt development ) could be more courageous than trying to solve all and everything in the QML runtime engine only - even if you have to touch code, where the authors are gone. My 2 cents, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Contributors' Summit 2019 - Registration open!
On 9/24/19 11:13 AM, Bogdan Vatra via Development wrote: Considering that QtCS and QtWS are both in Berlin and both in Nov, is there any reason why QtCS date was not choose immediately after QtWS (7-9)? Actually I was asking myself the same. I don't know if anyone is interested in what I'm working on, but as I'm considering to go the QtWS a connected QtCS would have been a chance to find out. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] [SPAM] Re: Qt 6: inline namespace Qt
Spam detection software, running on the system "mx.qt-project.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/6/19 4:27 PM, Mutz, Marc via Development wrote: > Yes, and no. No, the enums are still defined in namespace Qt. Yes, the > Qt:: prefix is then optional, so a user name AlignLeft would conflict at > the source level, giving a ambiguity error, fixable by explicit > prefixing with Qt:: [...] Content analysis details: (4.1 points, 4.0 required) pts rule name description -- -- 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4985] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 0.0 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS 2.3 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla --- Begin Message --- On 9/6/19 4:27 PM, Mutz, Marc via Development wrote: Yes, and no. No, the enums are still defined in namespace Qt. Yes, the Qt:: prefix is then optional, so a user name AlignLeft would conflict at the source level, giving a ambiguity error, fixable by explicit prefixing with Qt:: But how to fix the ambiguity if you want the "user name AlignLeft" - by writing ::AlignLeft ? And what if AlignLeft is defined in some third party library header. The author of that library might not even know about Qt, but the application that uses that library together with Qt will run into compiler problems. My 2 cents, Uwe --- End Message --- ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 story
On 6/3/19 2:35 PM, Bernhard Lindner wrote: What would be your story proposal? "Make Widgets great again"? That would be one I would like to see. But the story I'm actively working on is about a different Qt/Quick framework. I hope, that we are allowed to give a presentation of what this is supposed to be at the Qt World Summit. Unfortunately the Qt project seems to be clueless about how to deal with projects being developed outside. I tried to get an answer to the simple question how my work could be related to the Qt project. But even after a face to face meeting with Lars I never got any type of response. Neither positive nor negative - only silence. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 6/3/19 1:34 PM, Kevin Kofler wrote: So I disagree with the assertion that Qt needs more features to remain competitive. Come on - a toolkit ( Qt/Widgets ) for writing user interfaces, that does not make use of the graphics hardware, is begging for being replaced. Quick Controls 1 was once supposed to be such a replacement, but it failed to a degree, that it became a candidate for removal for Qt6. A technology that needs more than 30 QObjects to create a button simply has no rights to survive only because of compatibility considerations. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 6/3/19 10:50 AM, Giuseppe D'Angelo via Development wrote: How is this even an argument? Qt will need to evolve and acquire features to remain competitive. The probably most important module - Qt/Widgets - sits on a graphic stack, that had been identified as not being competitive many years ago. The only reason why the module ( = Qt on the desktop ) remains competitive is the lack of competition - including Qt/Quick modules. My expectation for a major release like Qt6 would be to see Qt/Widgets being migrated to the newer graphic stack - even if this would result in substantial API incompatibilities. Actually each major release should have a story, that has to do with some sort of innovation that might require to remove old stuff. But Qt6 does not seem to have something like this and why is it necessary then f.e to remove deprecated/failed modules like QC1 ? Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
On 5/24/19 2:30 PM, Giuseppe D'Angelo via Development wrote: We're talking about code that users should _stop_ using anyhow, and port away from it, right? Please also consider the situation of 3rd party libraries ( like Qwt ), that have to support Qt5/Qt6 from the same code base - probably for many years after Qt6 has been released. Currently Qwt supports all Qt version >= Qt 4.4. Qwt 5.x did even support Qt3/Qt4 from the same code base, what was a nightmare as you can imagine. In my daily work project we also have a set of core libraries, that run on old hardware with Qt4/QWS and on more recent projects with Qt5. ciao, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
On 5/21/19 4:58 PM, Thiago Macieira wrote: Note I said QtXml is deprecated, but it might actually be in Done state. I don't remember. Does anyone? Where's our authoritative source? The difference between Done and Deprecated is whether we're telling you to start porting code away. My use case is SVG, that depends on XML - using vector graphics is something we are doing since many years all the time. F.e our current project uses > 1000 SVGs. I remember, that there once was a page in the Qt docs that explicitly recommended layouts + vector graphics being the solution to make an application independent from the specific screen resolution. F.e QSkinny is based on a class QskGraphic ( https://github.com/uwerat/qskinny/blob/master/src/graphic/QskGraphic.h ), what is a QPainter record/replay paint device - similar to QPicture - that can be used like QPixmap/QImage, but for vector graphics. Our instances if QskGraphic were initially created from SVGs using this precompiler ( https://github.com/uwerat/qskinny/blob/master/tools/svg2qvg/main.cpp ) based on QSvgRenderer. Of course I could use a different SVG parser to create the QPainter commands, but for what ... So please don't consider removing SVG/XML - I would even suggest the opposite: improve Widgets + Quick towards vector graphics. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it
On 3/24/19 2:53 PM, Allan Sandfeld Jensen wrote: ... and I also advocate for the OpenGL engine. Agreed as this is one is available on Windows as well. But unfortunately OpenGL and X11 have been dropped with Qt5 and while X11 had returned with Qt 5.10 I'm not aware of a replacement for "-graphicssystem opengl". Being a member of the Qt Company you have the chance to change the situation ... I am just trying to explain why it isn't default and why switching to using the native engine isn't an automatic win. No, you wrote: "for most applications Qt raster engine is faster". This was exactly the argument I heard, for making raster the default graphics system on X11 with Qt 4.8 and finally removing the X11 paint engine with Qt5. Not being an "automatic win" is not even close to explain these decisions. Please note, that my system has some onboard Intel GPU - guess nothing could be more average than this. When adding NVIDIA and Radeon chips you are close to 100% of what is running on desktop systems nowadays and I never heard, that many of them are lacking X11 support. I would agree, that drawing a polyline of so many points is a corner case - IMHO running remote X11 is more often used. But without naming a more relevant use case, where the raster paint engine shows a significant better performance, your statement is coming out of nowhere. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it
On 3/24/19 1:21 PM, Allan Sandfeld Jensen wrote: As for the code you showed, that is so 90s. Please enable anti-aliasing, and try again. Or do any kind of advanced pattern or line endings and joins. Again: we are talking here about something like an oscilloscope, where we have to draw a polyline as fast as possible. Do you really expect "anti-aliasing, advanced pattern or line endings and joins" anyhow relevant, when a curve of many points has to be rendered several times a second. But o.k. let's enable antialiasing: now the performance is so horrible, that I had to reduce the number of points from 10 to 1000: - Raster 10561 - X11 1566 ( Note that 1000 points with antialiasing take longer than 10 without ) How is this helpful for your statement about "Software Rendering being faster" and why do we have to talk about antialiasing, when it ends up in a total performance disaster for both backends ? Come on this is a technical discussion - not about winning. I have no problem with being corrected, but you have to come up with some relevant facts. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it
On 3/24/19 1:13 PM, Allan Sandfeld Jensen wrote: Because imperative in the case of QPainter means immediate. The result is expected to have been committed to the paint device when the call returns. In case of the X11 paint engine this means that the points have been sent to the X server - not that any rendering has been done. From the application point of view this is not that different to putting the points to a scene graph node, beside that some interprocess communication is involved. You put your points somewhere and continue with whatever needs to be done. Guess the scenegraph solution will need more memory, but this is a different story. The creates extra overhead, due to a lot of small OpenGL calls constantly changes states and issuing short non-batched draw calls. Here we are talking about a single QPainter::drawPolyline. I bet it finally ends up at exactly the same call regardless if you use QPainter or the scenegraph. While a lot of what you are saying is true in general it is not helpful to constantly ignore the specific use case of Denis. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Does iMX6 support EGL on X11 feature?
On 3/22/19 8:28 PM, Konstantin Tokarev wrote: BTW, if your main concern is the performance of real-time plotting, it's extremely unlikely that you'll get better results on EGL/X11 than on EGLFS or EGL/Wayland. Note that you can use QWidgets on any of these platforms without restrctions. Not being able to run the X11 paint engine is the restriction. Using the OpenGL paint engine is a replacement in terms of performance, but it does not have the same quality. Using the OpenGL paint engine as backend in general was possible with Qt4, but with Qt5 only widgets being derived from QOpenGLWidget can do this - what excludes all standard widgets you find in Qt. What hurts most about the OpenGL paint engine in the context of Qwt is that it has an offset of 1 pixel compared to what the raster paint engine does. Also the result between X11 and Raster differs, what is a major pain, when you need to be pixel perfect. It is unfortunate, that a toolkit that has "cross platform" as major selling point has these type of incompatibilities, but this is how it is. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it
On 3/24/19 10:41 AM, Allan Sandfeld Jensen wrote: Note though that the recommended way of doing hardware accelerated painting these days with Qt, is using QML or the QtQuick scenegraph from C++. QPainter being so sequential and imperative will never be able to take full advantage of OpenGL because the API wasn't designed for it. For an application, where you have to draw a curve of many points, that are changing with every frame I don't see how the scenegraph is beneficial. And why do you consider imperative vs. declarative being relevant here at all ? Everything that happens before passing the points to the GPU is overhead, what means doing native X11 or OpenGL calls should be best. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it
On 3/23/19 11:09 PM, Allan Sandfeld Jensen wrote:
Software implementation is the default for X11 painting, with accelerated
paths being addons.
Having those addons is usually pronounced as: the system supports the GPU.
Sure there are systems, where this is not the case and things fall back
to software rendering - but we shouldn't give the impression, that this
is the average situation of systems running X11.
But for most applications Qt raster engine is faster.
The use case of Denis is about QPainter::drawPolyline - so let's have
some numbers for Qt 5.12 and QT_XCB_NATIVE_PAINTING enabled ( code
inlined at the end ):
- Raster: 6780
- X11: 683
( When using a pen width of 0 raster is only 3 times worse )
Without the extra copying out of the pixmap ( QPixmap::toImage() ) I
have this number:
- X11: 200
The main effect here is that application and X server run in parallel.
For the use case of Denis this is relevant as the application could work
on creating the points for the next frame.
---
So this is obviously a use case, where Raster is worse - when doing
remote X11 you have another important one. On the other hand I have
never seen a paper, where this "for most applications Qt raster engine
is faster" message is coming from or what type of use case it refers to.
Maybe it is only me who missed this information, but if you know more or
have numbers supporting your statement: please share them.
Actually the information what graphic pipeline is best for which type of
use case should be found in the Qt docs - in the best case with a solid
explanation. Otherwise this myth about software rendering being faster
continues to be told again and again.
Uwe
---
#include
#include
#include
#include
#include
void draw( const QPolygonF , QPaintDevice )
{
QPainter painter( );
painter.setPen( QPen( Qt::black, 2 ) );
painter.drawPolyline( points );
painter.end();
}
QImage renderRaster( const QPolygonF )
{
QImage img( 1000, 1000, QImage::Format_RGB32 );
img.fill( Qt::white );
QElapsedTimer timer;
timer.start();
draw( points, img );
qDebug() << "Raster" << timer.elapsed();
return img;
}
QImage renderX11( const QPolygonF )
{
QPixmap pm( 1000, 1000 );
pm.fill( Qt::white );
QElapsedTimer timer;
timer.start();
draw( points, pm );
const QImage img = pm.toImage();
qDebug() << "X11" << timer.elapsed();
return img;
}
int main( int argc, char *argv[] )
{
QApplication app( argc, argv );
QPolygonF points;
for ( int i = 0; i < 10; i++ )
points += QPointF( qAbs( random() ) % 1000, qAbs( random() ) %
1000 );
const QImage img1 = renderRaster( points );
const QImage img2 = renderX11( points );
qDebug() << ( img1 == img2 );
}
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Does iMX6 support EGL on X11 feature?
On 3/24/19 9:33 AM, Denis Shienkov wrote: Yes, I too run X11 on my iMX6 board, but, seems it running without of any acceleration (I use -platform xcb option to run my app). Unfortunately I don't have easy access to our project running on the iMX6 board anymore. But our BSP was made with buildroot and IIRC we had to do several patches there, before we had proper X11 support. And when the BSP does not support hardware accelerated X11 Qt is not able to fix this. But the iMX6 is one of the official target platforms for the "Qt for Device Creation" product ( https://doc.qt.io/QtForDeviceCreation/qtb2-index.html ), what makes it very likely, that someone can give more information about the situation on this device. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it
Ön Fri, 22 Mar 2019 17:06:32 +0100, Allan Sandfeld Jensen wrote: Sounds like XCB isn't as well optimized as Qt is Nice joke - but only when X11 falls back on some software emulation it might be the case, that the Qt implementation is better than that one. Note though, that there are number of techniques to make the native painting faster, such as always using qpixmap so the images stays buffered on the server side. Unfortunately after removing the X11 paint engine with Qt5 the Qt development started to rely on the fact, that QPixmap::toImage() is a cheap operation - what is not true anymore since Qt 5.10 and QT_XCB_NATIVE_PAINTING. F.e. in qquickpixmapcache.cpp you find code like this for creating textures for QQmlImageProviderBase::Pixmap: QQuickTextureFactory::textureFactoryForImage( pixmap.toImage() ) ); Here Qt/Quick is affected, but I have seen stuff like this in the Qt/ Charts module and there are probably more ... You might be able to massage your program to be faster with native painting, but the whole reason for switching to Qt side painting was that for the average application developer Qt side was faster. Not sure what "average" means, but when talking about vector graphics this nothing but wrong. I had posted statistics some years ago showing how much slower software rendering for the type of use case you have with Qwt: my test was about creating the same QImage using QPainter::drawPolyline in 3 ways: - Drawing to a QImage ( = raster paint engine ) - Drawing to a QPixmap + copying it out to a QImage ( X11 paint engine ) - Drawing to an FBO + copying it out to a QImage ( OpenGL paint engine ) I don't have the numbers anymore, but IIRC on my box OpenGL/X11 were > 10 times faster than what the raster paint engine does - even if the numbers include an irrelevant QPixmap -> QImage operation for OpenGL/X11 and the time for the QImage upload for the raster paint engine path is missing. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Does iMX6 support EGL on X11 feature?
On Fri, 22 Mar 2019 19:06:24 +0300, Denis Shienkov wrote: I'm trying to build a Yocto image, but the config tests fails on 'executing config test egl-x11' test with: We have an iMX6 board running with X11, so in general it should be possible. But this is using an early version of Qt5 - before QT_XCB_NATIVE_PAINTING had been added ( 5.10 ). It is some years ago and I was not part of our BSP team, but IIRC the Vivante support didn't work out of the box and we needed some patches to get things running. Our use case is running a Qt/Quick application - the motivation for using X11 here is that we needed VNC support, something that was not available for EGLFS at that time. Nowadays I would consider the X11 paint engine being an argument for running X11 - even with Qt/Quick - once you have expensive QPainter based code and you can't live with certain problems of the OpenGL paint engine. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it
On 3/22/19 5:19 PM, Denis Shienkov wrote: My goal it is to accelerate my QWidget application in some way... I use the QWT library to render a curves.. When setting QT_XCB_NATIVE_PAINTING ( Qt >= 5.10 ) you are usually running into an hardware accelerated path, that is much faster, than what you get from the raster paint engine. That's how it is on all systems I'm running. If this is not the case on your system I would expect, that there is something wrong with your X11 setup. So the first thing I would try is to do some tests on a Linux/X11 desktop system to be sure, that it is indeed an issue of the BSP on your board. Is any suggestions to minimize the CPU load on iMX6 target (using QWidget application)? Maybe is it possible to use an OpenGL at all with X11? OpenGL has a lower quality without being any faster, than the hardware accelerated X11. And if your X11 setup on your board is not o.k. than the OpenGL path is probably not better. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Continuous Integration for 3rd party projects using Qt
Hi all, in the end all advice goes into the direction of using one of the standard services in combination with using my own brain when working on the code. Unfortunately nobody pointed out a realistic way how a 3rd party project could make use of the infrastructure used by the Qt project nor did anyone seem to like this idea enough to think it through. Anyway - thanks for all the valuable thoughts and links, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Continuous Integration for 3rd party projects using Qt
Hi, thanks for the all the hints in this thread - I will check them if I can't find a service, that is more specific: a) The very first of my problems is to know about the platforms I need to test. I guess the list of all operating system and compiler combinations can be found somewhere in the Qt docs, but considering, that only on "Linux" you have to consider gcc/icc/clang - for gcc only you have v4/5/6/7/8 ... b) Furthermore a project like Qwt supports all Qt versions >= 4.4. Even, when limiting the tests to a set of relevant versions - let's say 4.8/5.6/5.9/5.12 - complexity grows significantly. -- My guess is that setting up all the build environments for a) is what has been solved with Coin. Actually I'm not interested in "continous" - it would be good enough to compile all my stuff once in a while ? Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Continuous Integration for 3rd party projects using Qt
Hi, all arguments for doing Continuous Integration for Qt ( https:// blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ ) are also valid for 3rd party code using Qt. F.e. with Qwt ( https://qwt.sourceforge.io ) I'm supporting trillions of environments I have never seen myself. Actually I'm using Linux/gcc only - the rest is crossing my fingers and hoping for bug reports. So what I'm looking for is a service, where I can upload my project to be built in all official combinations supported by Qt - like it is done for the Qt code. Is such a service available or - if not - would it be possible to open your CI system for community projects using Qt ? Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
On Fri, 11 Jan 2019 09:16:12 +0100, Samuel Stirtzel via Development wrote:
> There is a property that enables OpenGL rendering for _some_ plots
What will work when using QChart as QWidget, but I would assume that it
does not have any effect for the QML path - QPainter on QImage is
hardcoded in the QML wrapper.
> However my guess is that most users expect something as simple as this:
> BarChart { model: myData } and they don't care about how it works as
> long as it works.
Bar charts, pie charts and other type of business charts usually fall
into this category. And for this type of use cases Qt/Charts is probably
o.k.
But when you are looking for technical plots you need a framework like
QGraphicsView and friends. Trying to cover this type of use cases with a
declarative API ( setter/getter ) only, is simply a bad idea.
Uwe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
On Thu, 10 Jan 2019 14:21:59 +, Kari Oikarinen wrote: >> True, but Qt/Charts is also QWidgets only. >> > Not quite: https://doc.qt.io/qt-5/qtcharts-qmlchart-example.html According to https://code.woboq.org/qt5/qtcharts/src/chartsqml2/ declarativechart_p.h.html this is a wrapper around QChart. See the private section. But more important: as far as I can see it creates a QImage with QPainter, that it is finally converted to a scene graph node: see DeclarativeChart::renderScene. It's the first time I checked this code, but if I'm right I would say, that with Qt/Chart over QML the plot scene is never rendered hardware accelerated ! This is actually worse than any other pure widget based solution - including Qt/Chart widgets - that could at least take advantage of using hardware acceleration over X11 or OpenGL. Of course the performance of DeclarativeChart could easily be improved by adding the option of using QPainter on a FB0 ( or at least using a QPixmap, that would help for X11 ). But the fact that this has not been done so far makes me believe, that heavy and/or frequently updated plots are not considered as being relevant. Note that being able to create an Image/Pixmap/FBO with QPainter is something you find in every plot package - like you can also do this with any QGraphicsScene. Wrapping it into a QQuickItem, that converts the result into a texture is not much of a deal if you are familiar with the Qt/Quick C++ classes. So what has to be done for binding a plot widget to the scene graph and for building a declarative API on top, that can be exposed to QML, is more or less the same for any type of plot widget. It's a wrapper around the plot classes and therefore no strong argument for not using an existing solution. But anyone who knows better: please correct me if I'm wrong. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
On Thu, 10 Jan 2019 13:24:14 +0100, Vlad Stelmahovsky wrote: > Qwt is nice but supports only QWidgets, right? True, but Qt/Charts is also QWidgets only. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
On Thu, 10 Jan 2019 10:48:37 +, Tuukka Turunen wrote: > Related to your comment about the Qt Charts being limited I would tend > to disagree. https://www.qtcentre.org/threads/69718-QChartView-and-QScatterSeries- overrdide-the-label-of-a-QPointF https://www.qtcentre.org/threads/69094-3D-Plot I leave it up to you to google for more ... You might have noticed, that questions on the Qt mailing lists regarding Qt/Charts mostly end up in not being answered, but at least you find this statement from the maintainer: https://lists.qt-project.org/pipermail/development/2016-November/ 055337.html If you prefer "simple charting" or "not be the be-all-end-all charting solution" over "limited" - I don't care, we can agree on Miikkas wording. But it doesn't affect my conclusion, that Qt users ( including your customers ) would have a better solution, if you would have contributed to an existing 3rd party library instead of reinventing the wheel. > Discussion about Qt Charts is of course welcome, but perhaps not that > relevant for discussion about creating a new repository for Lottie-Qt. True, but Qt/Chart is a good example of what happens, when ignoring existing 3rd party software without technical reasons. And on a more general note: if LGPLv2+ makes code not being appropriate for the Qt project, then don't be surprised that you are not attractive for developers without having a business case in mind. My 2 cents, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
On Thu, 10 Jan 2019 07:24:01 +, Frederik Gladhorn wrote: >> Ours is LGPLv2+ as usual, FWIW. > > Which sadly makes it unsuitable for inclusion in Qt. I'm maintainer of the Qwt library ( https://qwt.sourceforge.io/ ), that exists since Qt 1.1 - but there are also other popular Qt plotting libraries available. For some reason "Qt" decided to come up with the Qt/ Charts module many years later - AFAIK without even trying to contact any existing project. As being author of a competing package I never checked the code of the Qt/ Chart module and can't ( and don't want to ) judge if it is good or bad. But my impression is, that it started with a limited set of features and immediately changed into maintenance mode without seeing much active development since then. Don't you agree that supporting an existing project instead would have lead to a better overall situation for everyone ? Considering that you hardly get the existing modules maintained - why don't you start with thinking in a more community oriented way ? Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
On Mon, 19 Nov 2018 20:00:30 +, Volker Hilsheimer wrote: > I understand that the “need more info” -> auto-closing bot workflow is > to some degree a bit of a probe to see if someone still cares. A bug is a bug and if the one who has reported it has lost the interest in it months/years later - usually because not working on the project anymore - should not matter. But maybe the mentality of a commercial product is different than mine. > When do you consider a bug report “lost”? When bug report does not end with a conscious decision of a developer. > So, leaving it in a “I’ll fix this when I get to it” kind of > state is rather not helpful. If the state would be true, I don't have a problem with it. But I can't remember any bug report, that ever left this state after being there for longer than - let's say 2 weeks. Actually I already stopped reporting bugs in areas, where you end up with assignees, that are known as a pseudonym for /dev/null. F.e the QPA/EGLFS stuff is full of problems, when working with multiple touch screens. But obviously this is a rare combination and the Qt Company seems not being interested - or lost the competence - in fixing it. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
On Mon, 19 Nov 2018 16:36:45 +, Shawn Rutledge wrote: > Also, every week we have a team of 2 people triaging bugs. Part of that > job is to check all the bugs that are in “need more info” state, and > decide whether the info is now sufficient. In the case of my bugs: in one of them it is totally unclear what additional info is required or who is the one who should provide more info. The only thing that seems to be clear is that it is not me, who is asked. In the other case setting the "need more info" state looked more like playing ping pong with the reporter ( = me ). Nevertheless I tried my best to answer, but was not aware of having to hit an extra button. But both bug reports have at least been looked at. I have others with much higher importance, that have been prioritized and assigned once and then - silence forever. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] automated bulk change closing old issues in the "Need more info" state
Hi all, I just received 2 messages about: automated bulk change closing old issues in the "Need more info" state. - https://bugreports.qt.io/browse/QTBUG-68874 - https://bugreports.qt.io/browse/QTBUG-66264 I have no idea why they have been set to "Need more info" - actually one of them has been explicitly answered, but the developer does not follow up. ( There might be other good reasons closing these bugs, but waiting for more info is definitely not the case ) I guess my bugs are not the only ones and if you don't want to lose a lot of valuable reports this way better stop an revert this bulk changes. Why should anyone continue reporting bugs, when all what happens is, that they are put on hold and finally closed automatically ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenSSL 1.1.x support on Qt 5.6, 5.9
On Mon, 12 Nov 2018 10:29:15 +0300, Valerii wrote: > Sometime need to use Qt 5.6, ... Qt 5.6 is LGPL V2, what means the Qt company ( ~= Qt Project ) has a strong interest in not supporting it - especially for environments where yocto is made for. So if your platform wants to make a LGPL V2 offer, a fork is probably your best option - if not already done by many others. ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Opinions on QTBUG-71545
On Mon, 05 Nov 2018 21:31:26 +0200, Konstantin Shegunov wrote:
> 1) Is parenting to the application object a thing?
The title of the bug report is about QCoreApplication, while the demo
code is a QApplication - so I'm not 100% sure if I completely understood
the discussion.
But at least for QApplication I would consider having children being
common practice and actually Qt does this too:
int main ( int argc, char **argv )
{
QApplication a( argc, argv );
a.setStyle( "Windows" );
qDebug() << a.children();
...
}
=>
QPAEventDispatcherGlib(0x10a9af0)
QSessionManager(0x10ac560)
QWindowsStyle(0x10b34f0, name = "windows")
Uwe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Who is in charge of qt-project.org?
On Thu, 01 Nov 2018 11:23:31 +, Tuukka Turunen wrote: > Of course mailing list discussion is also completely fine. It is more than that: it is the place where all fundamental decisions concerning the Qt project ( like f.e. deprecating modules ) have to be announced and discussed first - before writing devastating blog posts. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Who is in charge of qt-project.org?
On Thu, 01 Nov 2018 10:24:16 +, Tuukka Turunen wrote: > Things can always be improved, and constructive feedback is always > welcome. The bottom line of this all is of course the fundamental question if the Qt Project is intended to be more than simply a way how to contribute to the products of the Qt Company ? If it isn't it would be a matter of honesty to move everything from qt- project.org to qt.io and tell the truth to the Qt community. Otherwise he Qt Company has to give the Qt Project more rights to make independent decisions - starting with having a clean separation between the resources owned by the Qt Project and the Qt Company. > If you have suggestions, these can be done e.g. via: > https://bugreports.qt.io/projects/QTWEBSITE. Are you seriously trying to redirect complaints about how the Qt Company is misusing qt.project.org to qt.io ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
On Tue, 30 Oct 2018 19:24:26 +, Adam Treat wrote: > Lars gave a keynote saying pretty much the same. Simply is not true that > we are planning major source compatible breakage for Qt6 so let's stop > saying that. When will the already deprecated QQuickControls 1 module going to be finally removed - isn't it Qt6 ? QC1 user interfaces for embedded have to be migrated to QC 2, while user interfaces for the desktop have to be reimplemented from scratch with Qt/ Widgets in C++. To me this absolutely justifies to insist on the term "major". Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Metatype system in Qt6
On Mon, 29 Oct 2018 18:46:18 +0100, Olivier Goffart wrote: > In Qt5, we also need the name for the string-based connection syntax. I'm not sure if I'm ontopic for the Metatype system with my comment, so please excuse me if I'm hijacking this thread for a moment. I have this code: https://github.com/uwerat/qskinny/blob/master/src/common/QskMetaFunction.h https://github.com/uwerat/qskinny/blob/master/src/common/ QskMetaInvokable.h This code is for situations, where registering callbacks ( slots ) is needed, but without having a signal or a sender, that is a QObject. F.e like what you have with QTimer::singleShot. Our most important use case is a local bus system, that connects events coming from a system using Sun RPC with slots or property values. As we have several 100 pages each having lots of controls we don't want to create dummy sender Objects only to be able to call a slot and I ended up with diving into template programming myself. Would it be possible to make all this template based stuff for setting up callbacks more independent from being used with signals in Qt6 ? ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote: > What Lars said, if I read the email properly, is that the Qt Company > does not see a business value in developing it further. Yes and this is relevant if it is relevant for the maintainers of Qbs. Do we have a statement from them so far ? > But the project is open source and the code is there and anyone is free > to take over if they are interested in it. In case a maintainer decides to step down the normal process would be to find a new one. Only if this is not possible further steps have to be taken. Using Qbs for building Qt has been discussed here and lead to a solid decision against it. Obviously then the Qt company decided not to work on this code anymore - so far so good. But deprecating Qbs as a tool for building user projects is absolutely not covered by this discussion and if there was a more related one I seem to have missed it. This all has a lot to do with the question if the Qt Company sees itself as being a member or the owner of the Qt project. If we really want to be a community project, then the process of inventing and deprecating modules has to become more independent. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Mon, 29 Oct 2018 00:53:01 +0100, Lydia Pintscher wrote: > PS: As someone on the fringes of the Qt Project some emails in this > thread sadly make me see part of the project in a different light. I'm not too much interested in the topic of an CoC - not even in the discussion about it - but that doesn't mean, that it should not be allowed to have it here. But in this whole thread there is indeed one posting, that annoys me - and this is yours. I will never understand, why someone feels entitled to judge others so easily - and in your case without even giving any indication about what you are referring to. > I fear I'm not the only one. I guess you are. Nothing for ungood, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Wed, 24 Oct 2018 07:17:09 +, Ulf Hermann wrote: > Please review it. Qt Community, Qt Contributors, Qt Project, Qt Company - these are different things and whenever I see someone who is speaking in behalf of the Qt project I'm wondering who is actually speaking. The document already has the problem, that it seems to be legitimated by the Qt Contributor summit, what somehow implies that contributing is the criterion for having a voice in the Qt project. Furthermore you have this blurred line between the Qt project and the Qt company. IMHO a CoC for the Qt project is a chance to make things a bit clearer, by having a chapter about what type of business activities are seen as inappropriate in areas, that are owned by the Qt project. Or am I the only one who does not like being redirected to a page full of commercial content, when entering qt-project.org ? My 2 cents, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Mon, 10 Sep 2018 16:30:32 +0300, Denis Shienkov wrote: > but I don't see any differences using the QT_XCB_NATIVE_PAINTING=1 or > without of it. > The CPU usage still is a big ~71% in both cases. As long as you are updating the tick labels 10 times a second I would expect, that you have a CPU load, that is unrelated to your graphic pipeline. As said several times before: try to make your coordinate system more stable or at least reduce how often you are shifting. ( But this is offtopic for this mailing list ) > How I can know that the QT_XCB_NATIVE_PAINTING are applied? painter->paintEngine()->type() should return 0, when the corresponding paint device is a QPixmap or QWidget ( not QImage ). Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote: >> It also raises questions about the status of the X11 paint engine. >> Several bugs have been closed because of not fixing the X11 paint >> engine anymore. > > This being the reason why the X11 engine is not good for everyone. O.k. - but that does not answer my question regarding the status of the code ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Wed, 05 Sep 2018 13:04:39 +0300, Denis Shienkov wrote: > Uwe, wow :) What Qt5 version are you use? Seems to work with Qt5 >= 5.10. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Wed, 05 Sep 2018 09:56:36 +0100, Sérgio Martins via Development wrote: >> What needs to be done to make it become effective ? > > export QT_XCB_NATIVE_PAINTING=1 I did a quick check with using QPainter on a QPixmap and indeed it runs the X11 paint engine. Using Qwt with a current Qt version seems to run the same ways as with Qt4/X11 without any problems. So this is great news - at least for me, others might be aware of this option for a longer time. I also googled for QT_XCB_NATIVE_PAINTING without almost no results. I understand, that reverting a decision is not stuff for big announcements, but for such an important improvement: has it been communicated at least somewhere ? It also raises questions about the status of the X11 paint engine. Several bugs have been closed because of not fixing the X11 paint engine anymore. Does it make sense to write bug reports, when it behaves not according to the specs - or when it differs from what the raster paint engine does ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Tue, 04 Sep 2018 20:51:38 +0200, Martin Koller wrote: > added the native X11 graphicssystem support from Qt4 to Qt5 Very cool. Andrew told me that there were 2 concurrent attempts to revive X11 as the situation for running widget applications on remote desktops is simply not good, when using Raster. But I never realized, that finally something went into the Qt code base. What needs to be done to make it become effective ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Tue, 04 Sep 2018 14:38:47 +0300, Denis Shienkov wrote: > How I can do it for Qt4? Do you mean, I need to specify an appropriate > '-platform' option before starting of my application on Qt4? https://doc.qt.io/archives/qt-4.8/qapplication.html#setGraphicsSystem You can even run opengl as backend for all widgets this way, what might be an option for non X11 platforms. I should pay more attention to this option for future Qwt releases. The vertical lines of the rubberbands are clipped away because of the 1 pixel left shift of the OpenGL paint engine, but the ticks of the axes and the grid lines of the canvas are correctly aligned - in opposite to the Qt5/QOpenGLWidget combination. But please allow me to repeat the hint about trying the QwtPlotCanvas::OpenGLBuffer option. It introduces some overhead, but at least avoids doing the rasterization of the vector data with the CPU. It works with Qt5 ( even with EGLFS ) without having to fiddle around with QOpenGLWidget. All you need to do is to add one line to your code: plot->canvas()->setPaintAttribute( QwtPlotCanvas::OpenGLBuffer ); Uwe PS: this starts to become too offtopic for this list ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Tue, 04 Sep 2018 12:21:29 +0300, Denis Shienkov wrote: > Uwe, > what if I try to back-port my application from Qt5 to Qt4 with X11 > support (on iMX6). This is what I would try first in a situation like yours. Don't forget to set the graphic system to "native" - the default since 4.8 is raster. > As I understand, then I do not need to specify the OpenGL Widgets with > Qt4. Right and you might even see a lower CPU load depending on what happens in the various paint engines before calling the native libs. > Is it will help? Or do I need to use the QtQuick anyway? When looking at Arnos blog it looks like he has a stable coordinate system, where he only updates the curves with each frame ( please correct me if I'm wrong ). I would recommend to do this for your application too - having different tick labels with each frame will be an issue with all backends. In this situation you would have a positive effect for drawing the decoration of the plot canvas ( background/grid/... ) with using the scene graph. As the axes are different widgets with Qwt, they would not been updated with each frame - so the performance for rendering axes and tick labels does not matter here. But you could do something similar with QPainter by drawing these parts to a QPixmap once and reusing it for each frame. If you are interested - contact me at one of the Qwt support channels. For drawing the curves itself I wouldn't see many benefits from using Qt/ Quick as they do change with each frame. You might even have unwanted effects as you might need more memory - anyone who knows better, please correct me. IMHO I would expect, that you could get the optimal performance by doing native OpenGL with QOpenGLWidget::paintGL. But drawing a polyline of 400 points with 10fps should also be no problem on an iMX6 with QPainter/X11. But also note that Qt/Quick is much more than the scene graph. It is a technology, that includes a JavaScript experience and you always have a run time environment processing this code: if this matters is something only you can decide. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Mon, 03 Sep 2018 12:39:22 -0700, Thiago Macieira wrote: > Your criteria for "competitive" are different than the maintainers'. I was referring to the work of Gunnar and Kim, but comparing X11 with Raster and the quality of the implementation of the Raster paint engine are interesting topics as well. > You're not including the pathological cases where the X11 graphics > system didn't perform as well and required the raster engine to kick in. As being the maintainer of a cross platform library build on top of QPainter I have some experience in this area: when it comes to vector graphics X11 just rocks. Performance is much better and I never had all these bugs of Raster coming and going with every version. Actually my code is full of #ifdefs with enabling/ disabling workarounds for specific bugs in specific Qt versions. F.e: - https://bugreports.qt.io/browse/QTBUG-42398 - https://bugreports.qt.io/browse/QTBUG-70101 The situation for doing raster operations is the opposite. Actually I have code that fills QImages with gradients before drawing them to a QPixmap to get around X11 issues. -- Concerning the performance: the use case of technical plots is often about drawing curves ( unfilled painter paths, with a simple pen ) of many points. I once played with doing my own rasterization ( setting the pixels manually to a QImage ) by implementing a few algos you need: - https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm - https://en.wikipedia.org/wiki/De_Casteljau%27s_algorithm - https://en.wikipedia.org/wiki/Xiaolin_Wu%27s_line_algorithm Unfortunately I don't have the code anymore and of course it is not fair to compare a feature rich API like QPainter with something that is optimized for a specific use case, but: AFAIR the improvement was significant. > And you're not including the need to produce the exact same result in > all platforms. This is also a quite interesting topic, as the incompatibilities between the different paint engines is in fact a nasty problem. F.e. drawing a simple line with a FlatCap: for some reason it is specified ( https://doc.qt.io/qt-5/qpen.html#cap-style ) not to draw the "endpoint". Actually this not what the X11 paint engine does - never did - and you have a mismatch with Raster over all Qt4 releases. The OpenGL paint engine shifts everything by one pixel to the left compared to Raster. I thought I added a bug report for this very fundamental problem a couple of years ago, but I can't find it. Anyway, I'm not the only one: - https://bugreports.qt.io/browse/QTBUG-27500 Please note, that the final comment of this report indicates, that the incompatibility between raster and opengl won't be fixed, because X11 is no longer supported ! Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Mon, 03 Sep 2018 16:38:51 +0200, Simon Hausmann wrote: > ... it's not necessarily a > good overall investment of time when the scene graph provides a better > opportunity to get closer to the theoretical maximum of performance - by > design. In German we have the phrase: "Besser ein Spatz in der Hand als eine Taube auf dem Dach". For many situations I would already be very happy with having back the performance of what I can achieve with Qt4/X11. And IMHO the minimally invasive option would be QWidget/QPixmap ( not QOpenGLWidget ) being a paint device, that runs on a OpenGL paint engine. But if you even decide to migrate Qt/Widgets running on top of the scene graph - that would be fantastic news. Almost everything is better than to continue forever with a graphic pipeline, that is not even competitive with the one that had been sorted out in 2010. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote: >> From my experience with the QSkinny project I'm tempted to say that it >> would even be possible to implement the Qt/Widgets API on top of >> Qt/Quick core. > > So long as you ditch the paint event for most of the classes, leaving > the QQuickPaintedItem (or whatever it's called) only for the cases where > it's truly needed. When implementing widgets ( inside of Qt or 3rd party widgets like in Qwt ) it is mostly a matter of handling resize and paint events. The corresponding calls for Qt/Quick are QQuickItem::geometryChanged and QQuickItem::updatePaintNode(). So when trying to migrate widgets into being QQuickItems you would have to send QResizeEvents inside of geometryChanged and QPaintEvents inside of updatePaintNode. All of these "widgets" could have an FBO ( or QPixmap ) inside and creating a QPainter on a them would result in drawing to this one. Then it would be possible to create a scene graph node from it. Of course I'm heavily oversimplifying, but this way you would at least get something running in a reasonable amount of time - even if this would downgrade the scene graph into being a texture cache. But it would be a starting point for migrating the implementation of updatePaintNode widget by widget. -- But does it make any sense to spend time on this: In the context of Qt 5.0, where the strategy was to replace Widgets by Quick Controls 1 - probably not. But QC1 has become a failed technology and QC2 is not targeting the desktop anymore. So all what Qt has to offer today for the desktop is good old Widgets - running on a graphic stack, that is not competitive anymore. So in the retrospective IMHO the wrong decision had been made. And for the future - no idea, is there already a strategy how to satisfy desktop users with Qt 6 ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Sun, 02 Sep 2018 14:48:37 +0200, Jean-Michaël Celerier wrote: > For this kind of work I'd recoment QNanoPainter, ... I also gave this hint to Denis - without having any experience with it myself. When I have more time I will check if its is possible for Qwt to benefit from this backend. Do you have any numbers, when comparing the specific problem of drawing dotted lines ? Thiago argues, that a QPainter based render engine results in performance bottlenecks. But if it is possible to have significantly better results with QNanoPainter then there is no conceptual problem and Qt development could improve the situation by working on the code of the OpenGL paint engine. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Thu, 30 Aug 2018 15:47:34 -0700, Thiago Macieira wrote: > You can always just use QPainter on a QPixmap and paint that pixmap on > your QSGPaintedItem. It won't be particularly fast, but it will work and > do what you asked. After some conversation with Denis: the use case of this thread is a oscilloscope - drawing a polyline with ~400 points, 10 times a second. It is possible to reduce the CPU load from 100% to 50% simply by using a QOpenGLWidget as plot canvas. With raster we probably never reached 10 frames, so all we know is that the improvement is more than by factor 2. The rest seems to be related to the grid lines, and updating the tick labels on the axis. Updating the tick labels 10 times a second does not make much sense as nobody can read this. So I would consider this being an issue, that has to be solved on application side. But the grid lines are responsible for ~30% of the remaining CPU load, so let's spend some thoughts on this: drawing them requires a sequence of QPainter::drawLine calls ( maybe 10-20 ) with a pen width of 1 in Qt::DotLine style. Changing the style to Qt::SolidLine makes this part of the CPU load disappear - actually the CPU load becomes the same as when not drawing the grid at all. So I would guess that the CPU cycles are related to calculating the dots for each line before forwarding it to some OpenGL call. > If you want faster, redesign with OpenGL in mind. What does that mean for a task like drawing a dotted line and why do you consider application code being more effective in finding a fast implementation for this ? I would expect the author/maintainer of the OpenGL paint engine being an expert in how to use OpenGL in the most effective way and the job of this module should be to keep away those details from the application code. And what would be the benefit of Qt/Quick for drawing dotted lines ? How would it be different/superior compared to writing pure OpenGL code - f.e in QOpenGLWidget::paintGL ? And why should Denis use Qt at all if he is supposed to break down basic primitives to pure OpenGL himself ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote: > The result of (b) is a retained-mode scene graph. It's in the QtQuick > library. I know, but now we have Qt 5.11 and it is fair to review this result: the API of the scene graph - as it is today - is so far from offering a comparable feature set like the one you have with QPainter. Actually it does not even offer the most fundamental primitives like: - non rectangular boxes - text - ... Have a look at all classes in the public API being derived from QSGNode: it boils down to QSGImageNode, QSGRectangleNode, QSGSimpleRectNode and QSGSimpleTextureNode. Do you really recommend starting with only this ? All sort of code that implements the minimal set of primitives almost everyone needs is hidden somewhere in private code of Qt/Quick core. But even if this code would make it into the scene graph it would be far from what you get with QPainter. But QPainter is more: it is an API, that allows you to implement render engines that works with different backends - f.e PDF is often simply mandatory. So implementing a plot package on top of scene graph does not mean, that you can drop the QPainter code you have to do the work twice. Having the common API running on various backends is such a huge asset of Qt - maybe one of the most important ones Qt has to offer. I really don't get why so many Qt developers do not realize what you actually have in your hands. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Thu, 30 Aug 2018 14:26:34 +0300, Denis Shienkov wrote: > Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and > QwtPlotOpenGLCanvas does help a bit. The iMX6 CPU usage now is ~50% > (instead of previous 100%). A small correction for others reading this: trunk is Qwt 6.3. The main difference to the code you find in the 6.2 branch is exactly about the OpenGL canvases, where I need more time to find workarounds for the incompatibilities of the OpenGL paint engines. I also forgot to mention that Qwt from trunk also has the option QwtPlotCanvas::OpenGLBuffer. In this mode rendering is also done hardware accelerated - using the OpenGL paint engine to an offscreen FBO. Then the FBO gets copied to a QImage being rendered to a normal QWidget. This combination should also work with EGLFS. But of course copying from GPU to CPU and back for each frame might kill your performance requirements. Please let me know what you can achieve with this combination ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Thu, 30 Aug 2018 14:26:34 +0300, Denis Shienkov wrote: > Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and > QwtPlotOpenGLCanvas does help a bit. The iMX6 CPU usage now is ~50% > (instead of previous 100%). I have been attending one of the Qt roadshows last year in Munich. One of the speakers asked the audience which Qt versions they are using: I didn't have time to count them manually, but my rough estimation was that about 30% were still on Qt4. Assuming that almost all of them were Qt/Widgets users and there are others in the Qt5 groups I would guess that the majority was interested in Qt/Widget applications. Considering, that Qt/Quick Controls 1 has been given up it is fair to say that today the only reasonable option, Qt has to offer for desktop applications, is: Qt/Widgets. So to me there is an obvious mismatch between where the users are and what Qt development is working on. Concerning the future of Qt/Widgets I guess almost everyone wants to have hardware accelerated options - like what we had with Qt4/X11 or what could be done with OpenGL. The most recent related feature I'm aware of was introducing QOpenGLWidget with Qt 5.4. But combining QOpenGLWidget with standard QWidgets is unstable - see https://bugreports.qt.io/browse/QTBUG-50916 ). Furthermore nobody seems to be interested in working on the OpenGL paint engine. At least I have no explanation, why bugs like this one https:// bugreports.qt.io/browse/QTBUG-52672 are not being handled over years. ( actually this one is assigned to Gunnar, who is not even active anymore ). >From my experience with the QSkinny project I'm tempted to say that it would even be possible to implement the Qt/Widgets API on top of Qt/Quick core. Of course it wouldn't be exactly the same, but for standard desktop applications it should be possible to offer a migration path, that is not harder than what we had with Qt3 -> Qt4. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On Wed, 29 Aug 2018 16:43:40 +0300, Denis Shienkov wrote: > So, there are no way to improve an acceleration and to minimize the CPU > loading? It depends on the requirements of your application, but when it comes to oscilloscope alike widgets your best choice is Qt4/X11. The X11 paint engine is hardware accelerated, it even allows painting outside of paint events - what is important for incremental painting. ( The fact, that Qt 4.8 prefers using raster with the argument of performance it is totally nonsense, when it comes to any sort of vector graphics. ) Furthermore the X11 paint engine simply has a better quality. The sort of bugs coming and going with the various Qt versions is a nightmare for any sort of graphics framework. Actually my job for today is to find a work around for this one: https://bugreports.qt.io/browse/QTBUG-70101 -- If you need to go with Qt5 I would recommend to use a platform that allows for using QOpenGlWidget - X11 again is IMHO not a bad choice. Actually one of our terminals is a iMX6, where we do this ( because we needed VNC support ). Next I recommend Qwt from SVN trunk, where you can simply assign a QwtPlotOpenGLCanvas to achieve hardware acceleration. The quality of the OpenGL paint engine is not as good as X11 or Raster, but for a oscilloscope things usually do not need to be pixel perfect. -- Finally you should not ignore algorithmic options to reduce what has to be painted. How to optimize the rendering process is often quite individual, but often QwtPlotCurve::FilterPointsAggressive ( since Qwt 6.2 ) has a significant effect in oscilloscope alike applications. In fact I have been contacted quite often with oscilloscope applications struggling with performance issues and often it could be solved on a algorithmic level. As an inspiration you could also try to run the oscilloscope demo of Qwt on your board. You will notice, that it runs with almost no CPU usage because it mostly paints incrementally. Of course this only works because the design of the user interface is made for this, but maybe you can do something similar. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dark mode, palettes, styles etc.
On Fri, 06 Jul 2018 08:50:44 +, Shawn Rutledge wrote: > But there’s the > trend of using image-based styles more, which contributes to the > annoyance that you don’t actually have system-wide control over colors > and styles. At least for Qt/Quick I'm not sure if this a trend Qt has created by not providing powerful scene graph nodes to the user. F.e. one of the very first thing I did was to implement my own type of renderer for rectangles, so that I can do raised/sunken effects with rounded borders and vertical gradients. ( The frames/boxes examples in qskinny show those nodes - quality will be better once Qt-antialising has been added ). Also because Qt/Quick applications are often in fullscreen mode only proper layouting - like it is state of the art with widgets since decades - is not that common anymore. And again Qt/Quick has a responsibility in this as its layouts are not on the same level - even if having a powerful engine below. > So it just becomes more work for widgets, controls and > applications to have both sets of images, in addition to having > different resolutions for high-dpi support, whenever they are built that > way. I remember that once there was a page in the Qt/docs that recommended using layouts and vector graphic formats. Unfortunately Qt was never good at vector graphic formats - neither for widgets nor Quick. ( Actually this would be a wish for Qt 6 I would have ) FYI our application is completely made of SVGs ( more than 1000 different ) that work with different screen resolutions and color schemes. We are precompiling our SVGs into a painter commands at build time. Then the different colors inside those painter commands are replaced at runtime from the themes ( = skins in our terminology ). As our icons are simple and are made of few colors only, rendering them to textures is fast and we are able to interpolate between the colors for animated theme transitions without losing frames. ( The svgviewer example of qskinny shows it - our real application has this smooth transitions between skins for all controls ). > (So much > so that Shapes are a really recent addition, while Canvas and QtSVG > continue to use QPainter to render to a texture.) In the beginning of our project I compared creating our textures from SVGs using the OpenGL paint engine and the raster paint engine. Beside being buggy ( https://bugreports.qt.io/browse/QTBUG-52672 ) and having a worse quality with antialiasing the surprising result was: the OpenGL engine was slower. Not sure if this is still the case. If yes it might be because of the tesselation being more expensive than the actual rendering - but I havn't looked deeper into this. ( My test was done running over our 1000 SVGs - code can be found here: https://github.com/uwerat/qskinny/blob/master/examples/gbenchmark/ Benchmark.cpp ) > There is talk of rearchitecting QStyle in Qt 6. IMO this is a very > important feature we should take into account. Do you also already have specific plans about what to do with Qt/Quick core in Qt6 ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QInputMethod woes
Hi Simon, > While it's true that show(), etc. don't have the focus object as a > parameter, you do have a three ways Yes, sure: show() is not the problem. ( We also have situations, where the virtual keyboard is started by pressing a button, while the input should go to some sort of label - but let's forget about them here ) > I'm missing something then, why is your virtual keyboard hidden... It isn't. > ... when the > focus object transitions from an element in the regular UI to an element > in your virtual keyboard? Our keyboard is a container item having the tabFence/focusProxy flags being enabled. It is shown on QInputMethod::show and automatically gets the focus. Automatically transferring the focus on hide/show of popups ( = items with tabFence/focusProxy ) is part of the qskinny framework. ( in case you are looking for ideas for Qt6: almost every EGLFS application needs some sort of replacement for what a window manager does with regular windows ) But anyway - the text input loses the focus and one of the buttons inside the virtual keyboard receives it: then the first thing that needs to managed is, that whenever the focus changes - f.e when the focus gets transferred to the virtual keyboard, or simply when navigating along the buttons inside the keyboard - the input context receives QInputMethod::commit() requests. -- But let's also have a look at QQuickTextInput: it automatically calls QInputMethod::show, when receiving the focus. This makes the focus tab chain almost unusable, as the virtual keyboard pops up, only when trying to navigate over a text input - always stealing the focus. Then when closing the virtual keybaord and the focus returns to the text input: it immediately reopens the virtual keyboard. Automatically calling QInputMethod::show can be avoided by disabling the focusOnPress ( = Qt::ClickFocus ) property, but what to do, when it is needed ? So without hacking QQuickTextInput ( = accessing private headers ) on the C++ side you can't get any proper focus management working. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QInputMethod woes
Hi Simon, > But my initial guess is that this isn't an inherent design > problem of the input method API. Well, one problem is that the input context needs to know about the current item, as it has to correspond with it. But QInputMethod::show/ commit/reset/update/hide do not transfer any information about the item calling them. In case of show() all the context can do is to assume that the item having the active focus is the one to correspond ( what actually is not always correct in our application ) with. In case of all other calls the context has no chance to find out if the caller was the item it is corresponding with - at least not, when the active focus has moved somewhere else. And you find various situations in QQuickWindow or the controls, where inputMethod calls are done from items not being the corresponding one. F.e. in QQuickWindowPrivate::setFocusInScope/clearFocusInScope QInputMethod::commit() gets called, whenever the focus is changing. As this is might be wrong all our context can do is to ignore these calls in general. -- As we also implement our own type of controls ( in C++ ) I can work around most of these issue with bypassing the QInputMethod API and calling our context manually using a proprietary API, where I'm adding the caller as parameter. But this is obviously no option for the average Qt user. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QInputMethod woes
Hi all, when working on our virtual keyboard I had to realize that the design of QInputMethod is inappropriate to achieve what we need: a) the input method is tied to the item having the focus We have a touch screen but also an special input device, that offers a wheel to navigate along the focus tab chain and a few buttons like 'ok'. So the virtual keyboard is part of the focus tab chain and all its buttons need to be accessible with this input device. And here is where the implemented input method concept fails - as soon as navigating inside the virtual keyboard the initial input control loses the focus and the input method gets disconnected. b) multiple screens Our application runs on several screens, where it is possible to have several virtual keyboards - one per screen - at the same time. The singleton concept of QInputMethod does not support this at all. Maybe this is worth to be put on the list for Qt6 ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-43096 - QML instantiation performance decadence
Hi Tomek, > I quickly reviewed QSkinny and it really nicely exposes C++ to Qml. I > can't see however, how you made e.g. QskVariant::stops readable from > Qml. Writing stops is possible due to QMetaType::registerConvertes, but > how you can iterate overs stop from Qml? Don't know either, but I'm not the right person to ask when it comes to JavaScript related issues. > PS: I also tried to have the same implementation for C++ and Qt Qml and > now some classes contains duplicated getters/setters (QVariantList > instead of QVector). Hope it is o.k. to throw in some ideas/experiences, but as my work is not part of the qt-project I don't want to to misuse this mailing list. But if you ( or anyone else ) likes to discuss in more depth what I'm doing you can always contact me of the list. ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-43096 - QML instantiation performance decadence
Hi Simon, > I ran benchmarks comparing a release build of 5.12 against 5.1.1 and ran > the benchmark mentioned in the task, where Qt 5.12 came out in average > faster by a factor of 4. Christophers comment in the JIRA ticket raises some questions concerning the correctness of those benchmarks. Would you be so kind to clarify how far we can trust in these numbers ? Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-43096 - QML instantiation performance decadence
On Sat, 26 May 2018 12:05:38 +, Simon Hausmann wrote:
> P.S.: Are you sure the stops: [ ... ] assignment works?
You are right: I forgot to mention this extra piece of code:
QMetaType::registerConverter< QJSValue, QskGradientStop >(
[] (const QJSValue& value) -> QskGradientStop
{
return
{
value.property( QLatin1String("position") ).toNumber(),
value.property( QLatin1String("color") ).toVariant
().value< QColor >()
};
}
);
It can be found in https://github.com/uwerat/qskinny/blob/master/src/
common/QskModule.cpp.
Most of the tricks for exposing stuff to QML have been written by Andrew
( Knight ) who is way more familiar with the QML world than I am.
In the beginning we were not sure if we will be able to come up with a
framework, that allows us to get rid of QML in general. That's why we
played with ways how to expose our APIs to QML without creating the same
overhead you find in the existing classes.
Today the QML API is not in the focus of the application driving the
development of QSkinny. But from the initial proof of concept it is
pretty clear that I can expose - let's say 80-90 % of the API - to QML
easily.
But a Qt/Quick application is always a combination of QML and C++ and I
don't see why it is necessary trying to do as much as possible in the QML
part.
Uwe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-43096 - QML instantiation performance decadence
Hi Robin, > Why does it need to be? I have never needed to subclass QQuickControl, > personally, so I have never brought this topic up. For the same reason all other controls from QC2 do subclass it. If you want to participate in mechanisms ( like font/locale/palette propagation ) that are implemented in this base class, you have to. > There is a cost, yes. But I would say it's more a cost/benefit tradeoff. > Faster prototyping and development cycles at a cost of requiring some of > your resources to munch on. Please allow me not to respond: I would like to avoid ending up in yet another QML vs. C++ discussion. > Anyway, wrt direction, I assume you are hinting at a scenegraph that is > less tied to QtQuick. No, the scene graph is already a standalone module with a well designed public API: many thanks to the authors. Its API could be more comfortable and the existing set of nodes is underfeatured, but in general I have not much to complain. Almost everything is about the C++ classes of the various Qt/Quick modules. The majority of them is designed with having QML as the one and only use case in mind. I'm also not happy about how the scene graph is used inside of those classes, because it substantially contributes to the memory and startup performance problems of Qt/Quick. It took me some tome to get those things under control, but in the end it was possible without having to patch Qt code itself. > If you are volunteering ... I am - and you can already see more than 50K lines of code from my efforts. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-43096 - QML instantiation performance decadence
On Fri, 25 May 2018 14:30:05 +0200, Robin Burchell wrote: > I have over the years avoided using QQC1 in several projects as > I knew that the performance simply wasn't up to the task without ever > trying it "seriously", instead developing custom controls ... Please let me give a detailed answer to this one: On the Qt Conn 2016 Andrew ( Knight ) presented our very first results, when comparing 4 different implementations of an average button. a) a button from Quick Controls 1 b) a button from Quick Controls 2 c) a custom button composed in QML ( this is your approach ) d) a button from QSkinny All implementations have been done in QML with very similar code. Unfortunately the presentation has not been recorded, but out of my memory one of our statistics was: a) > 30 QObjects b + c ) 7 QObjects d) 1 QObject The reason why QSkinny is more lightweight is because it does scene graph node composition, where all other implementations are composing more heavy Quick items. ( But we also noticed stuff like that: QQuickGradient is a QObject and even QQuickGradientStop is one. So for the definition of a gradient with 2 colors you need 3 QObjects: > 400 bytes. These little things could easily being fixed by using Q_GADGET - but obviously nobody cares. ) -- Another example I can give is related to new code: the page indicator from Quick Controls 2. IMHO all what should be needed to describe such a control is the number of the bullets, the index of the current one, the shape of the bullets and maybe some color information - all in all maybe ~50 bytes. But the way how it is implemented is having a Quick Item for each bullet. IIRC an item has a minimum of 320 bytes ( usually more ) and has an extra transform node on top of its paint node. So we end up with something like n * 400 instead of ~50. Might be interesting to count the exact numbers being consumed with the existing styles - I would expect to end up with something scary. I don't want to insist too much on the page indicator example as this is usually not a control that is instantiated many times in the same application. But to me it is symptomatic and you find a similar situation almost everywhere. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-43096 - QML instantiation performance decadence
Hi Robin, > From my own perspective, I think Controls 1 was a well-intentioned ... Agreed and to be honest I'm really impressed about what was doable in QML, but it also showed where its limitations are. But at the time, when Controls 2 has been started everything was on the table and - at least from the outside - it looked like a comfortable situation for making good decisions. And this is what I had expected to happen: a) a solid C++ API with the same quality we are used from all other Qt modules. Then the majority of the API is already available for QML by the standard mechanisms of the Qt/MetaObject system. b) a thin layer on top to make the QML API feature complete. Unfortunately I never noticed any indication pointing into the direction of a better C++ support. In fact the opposite happened: even the very base class of all QC 2 controls is not part of the public API ! > These are the key reasons I closed the bug -- I think > that the message has been heard, improvements have been made, and > hopefully things are now consistently heading in the right direction. The stupid fact is that QML always comes at a cost. Trying to reduce these cost has been successfully done and any further improvements are welcome, but: as long as there is no clear separation between the Qt/ Quick graphic stack and QML I disagree, that the "right direction" has already been found. > You mention qskinny. I think that experimentation is very cool, and it's > great that it is working out for your project, and I am already familiar > with it, but I'm not too interested in it personally, simply because the > QML of "today" (having written a few libraries LOC of QML at this point) > generally works well enough for me, and I find the convenience of the > language very much worthwhile. QSkinny is not about QML vs. C++ - it supports both, and some of the provided examples are in QML. The reasons, why we are not using QML is because we decided so. And this is the opposite to our previous version, where we made the decision for QML because we had to. -- Maybe a word on my intentions about QSkinny: in the first place it is supposed to be the platform for the products of our company ( being in the automotive industry ). So writing the docs, polishing the skins ( = themes ) or completing the set of controls - steps that should be done to make the project more accessible - do not have the priority they deserve. But I believe, that it is a good starting point to make more out of the Qt/Quick graphic stack as what we see today. And if in the end nobody else is interested ( in using or contributing ) it is good enough to demonstrate what is possible. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTBUG-43096 - QML instantiation performance decadence
Hi all, this morning I got a notification about https://bugreports.qt.io/browse/QTBUG-43096 being closed. I guess many applications had been hit by this issue, but as I was related to the project that created this bug I would like to give my summary of what has happened since then: a) On the Qt development side a lot of efforts have been made to improve the QML problem. I don't want to be disrespectful, but the fact, that Controls 1 has finally become deprecated, because of ( IIRC ) "insolvable performance problems", it is fair say, that those were no game changers. So to me the only step that really matters was introducing Qt/Quick Controls 2. But what makes Controls 2 being superior compared to its predecessor ? AFAIK the answer is mostly about doing less QML, achieved by: - dropping features ( usually desktop related ) - internally done in C++ Of course this raises the question, why there is no offer for doing more in C++ on the application side, when it has been identified as the solution for implementing the controls ? And this is why I'm disappointed about Controls 2. Application code still has to be done in QML and when the majority of the GUI code is application code the benefits of Controls 2 are limited. b) On our side the the decision was made to go back to Qt 5.1, where the project is stuck until today. Almost all developers of the original team are gone - none of them recommending QML as technology for further projects. Even worse - some of them explicitly mentioned QML being a reason for leaving. So for the next generation of our product we started to implement our own framework on top of the C++ part of Qt/Quick ( https://github.com/uwerat/qskinny ). Our user interface today consists about ~200K lines of code ( pure C++ ) and so far I can say that the typical problems of having a bad startup performance or the heavy memory footprint simple don't exist. Unfortunately we still have to maintain our previous product written in QML for many years. Maybe we can migrate it step by step to our new framework. With all respect, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rendering only items that are visible in Qt Quick
On Fri, 23 Mar 2018 13:44:03 +, Mitch Curtis wrote: > As I understand it, clipping (the "clip" property) doesn't prevent items > that aren't visible (in the sense of being out of the viewport, not the > "visible" property) from actually being rendered. In my framework ( https://github.com/uwerat/qskinny ) I'm blocking scene graph nodes for all invisible items, and also played with an implementation doing the same for items being outside the window ( or some other clip ). The challenge is not about preventing unnecessary nodes - it is about, how to call update, when an item, that had been blocked before, comes into a visible region. Item coordinates are relative to the parent and there is no notification when the absolute coordinates have changed. Introducing such a notification means running over the complete subtree below an item each time its position changes. At this point I gave up as I didn't saw how to implement it without introducing other significant performance penalties ? > Comments about how it will never work and I should feel bad for > suggesting it? Well, I never found something being written in the docs, but from reading the code I got the impression, that one very fundamental concept of Qt/ Quick is: fill the caches ( f.e scene graph ) as early and as much as possible, so that you don't have any delays later. Of course you have to pay with memory and startup performance, but you can't have both. Just to mention it - my framework implements exactly the opposite strategy: don't do anything expensive before it is really needed. My 2 cents, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt branches & proposal how to continue with those
On Mon, 29 Jan 2018 06:59:06 +, Jani Heikkinen wrote: > - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict' > mode. This type of discussion has to be lead, before making a LTS promise ! Trying to change this later - without having any argument beside, that maintaining stable branches is cumbersome - makes your LTS promises nothing but unreliable. But IMHO you are also asking the wrong audience. Qt development is the right group, when discussing if a release should be a LTS one. But if you want to change the cycle of an existing LTS version you should ask those to whom you made the promise: the users. Speaking for myself: I'm only interested in LTS versions and I could easily live without releases that never go beyond 5.x.1 ( like f.e 5.10 ). Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Undeprecating QString::null
On Tue, 16 Jan 2018 18:38:48 +0100, Kevin Kofler wrote: > So just use QString(), or define your own static instance of it if you > really want to microoptimize it that much. No it is simply that the first version of Qwt was for Qt 1.2 ( before QString even existed ) and during a history of almost 20 years there are leftovers. I had missed the point, when the static instance had been replaced - that's why I was erroneously concerned about BC breaks. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Undeprecating QString::null
On Tue, 16 Jan 2018 17:54:43 +0100, Giuseppe D'Angelo wrote: > headers of 3rd party libraries > should be included under -isystem, not -I, to disable warnings in their > headers. Yes as there seems to be no BC break ( thanks to all correcting me, I should have a deeper look at the code before ) this is a reasonable recommendation - at least for platforms, where the option is available - I can give my users for now. Sorry for the noise, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Undeprecating QString::null
On Tue, 16 Jan 2018 17:26:51 +0100, Alexander Nassian wrote: > Deprecated since Qt4 ... According to qstring.h: #if QT_DEPRECATED_SINCE(5, 9) ... #endif But come this is not about me and if I missed, that an API has been declared as deprecated. It is about what to best in the current situation. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Undeprecating QString::null
On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote: > Just change your code to use "= QString()", no #ifdef necessary. The "just change" introduces a binary incompatibility - right ? Please be aware, that Qwt is part of almost any Linux distro - according to sourceforge it has more than 1000 additional downloads every week since many years. All distro maintainers would not only have to upgrade the Qwt packages, but also all packages depending on it - users would have to rebuild. Considering the strict compatibility rules you have for Qt you will understand, that this is nothing I would like to do easily. But could you please comment on why this change is an improvement - beyond getting rid of 3-4 lines in qstring.h ? Thanks, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Undeprecating QString::null
Hi all, I received a bug report concerning a header of the Qwt library ( http:// qwt.sf.net ), that is using the deprecated QString::null. Sure this is only a warning, but it is obviously something where Qwt users get irritated as they can't fix code of a 3rd party header. The offending line looks like this: QwtText( const QString & = QString::null, ... ); So my first question would be, what is wrong about using QString:null and why using QString() is better. My second question then would be if this is also for Qt4 ( Qwt 6.1.2 supports all versions >= Qt 4.4 ) and older versions of C++ and compilers. To be honest I don't want to create a new ( + binary incompatible ) version of Qwt and/or add even more version depending #ifdefs, as long as there is no good reason. ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt and IoT infographic
On Mon, 28 Aug 2017 21:41:15 +0200, Jean-Michaël Celerier wrote: > * apparently QQuickWindow has some ties to the QML engine but in my > experience you can just create new QQuickItem from c++ and add them as > child of the rootItem and it works. F.e. https://github.com/uwerat/qskinny does exactly this. This library is our platform for an ongoing development of a quite complex Qt/Quick user interface in the automotive area. Platform and application - both are written to 100% in C++. In case someone is interested in the qskinny project: it is under heavy development, but already good enough to demonstrate, what needs to be done to solve the memory footprint + startup performance problems. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Release plan moving forward
Hi Lars, > 5.6.3 is planned for Summer (current plan is August), close to 18 months > after the first release. So yes, the 'very strict’ mode would be coming > somewhat early, but more by 6 months than a full year. Or to put it this way: 5.6 LTS guarantees, that all serious bugs found during the 5.9 ( guess also 5.10 ) cycle will make their way into 5.6. > I am in favour of getting onto the ‘very strict’ path a bit faster ... Coming from the user point of view I would vote for at least not dropping support for any LTS version until the following one goes into 'strict’ mode. So in this case 5.6 would not go into 'very strict’ before 5.10 is released. But you already gave a promise for 5.6: breaking it easily, compromises LTS promises in general - also the one you would like to make for 5.9. ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Release plan moving forward
On Wed, 10 May 2017 09:21:37 +0200, André Hartmann wrote: > From Lars original mail: > > > Of course, we will also continue to support 5.6 for the promised > > three years. We are planning to release 5.6.3 in Summer, after which > > 5.6 will move into the 'very strict' mode as defined in the branch > > policy QUIP. Ah sorry - I missed that part. But when looking into the QUIP I read it as 5.6 is about to enter 'very strict' in the 3rd year - what would be summer 2018 considering the release of 5.6.0 ( March 2016 ) being the starting point, right ? So the announcement is about to cut the 'strict' stage by almost one year - what basically means a stop of fixing P0/P1 bugs 1 year before, what had been promised. Lars explains it because of new features in more recent versions. But being outdated is in the nature of any LTS release and IMHO can't be an argument for not taking the 5.6 promise seriously. ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Release plan moving forward
On Tue, 09 May 2017 13:35:52 +, Lars Knoll wrote: > So we are now planning to make Qt 5.9 a LTS release. It's been 3 minor > releases since 5.6 and a lot of good things have happened in Qt, so this > should be very good news to those of our users that don't always want to > be on the bleeding edge but are looking for a stable version that's > supported for a long time. Having more LTS releases is great, but I hope this does not mean, that support for previous LTS releases will end ? F.e. we have chosen 5.6 because of being a LTS release, hoping for "long" being something long. ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qdoc for C++ and QML
On Tue, 25 Apr 2017 06:05:38 +, Martin Smith wrote: > Use \internal in their qdoc comments to tell qdoc not to include them. What would be incorrect as those APIs are only internal for C++, but public for QML or v.v. And sometimes you have "see also" references inside of docs for a method that is for both languages, but the reference is linking to QML or C++ only methods. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qdoc for C++ and QML
On Mon, 24 Apr 2017 17:09:43 +, Martin Smith wrote: > It doesn't need a separate comment, just something in the one common > comment that indicates the class is both C++ and QML. Most of the decisions about what parts of the APIs have to go to the QML docs can indeed be made without any additional tags, but IMO there is still a need for being able to explicitly qualify certain parts as QML or C++ only. F.e I have a couple of C++ methods, that serve no other purpose than to make another C++ API accessible from QML. And the other way round I don't want to see the API, that is made for the C++ use case being visible in the QML docs - even if technically being invokable. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qdoc for C++ and QML
On Mon, 24 Apr 2017 15:08:25 +, Shawn Rutledge wrote: > I guess we haven’t run into this very frequently yet because so few > classes have both a C++ and a QML API within the same class. Well, this is exactly my use case. All my controls are 100% implemented in C++ offering a full featured C++ API. Having a usable QML API is a side effect you almost can't avoid, when doing it this way. I started to get the job done with doxygen and a homebrew filter, that preprocesses my docs by seperating the QML and C++ paths. But having something usable from Qt would be highly appreciated. Not sure if qdoc is intended to be useful for 3rd party libraries as well, but at least for my use case it would save me a lot of work. ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery?
On Tue, 22 Nov 2016 18:05:20 +0100, Friedrich W. H. Kossebau wrote: > Q1: what would be a good system path pattern (on *nixoid systems) for > Qt-based libraries to install their QCH files to? Qwt ( http://qwt.sf.net ) offers a qch file and is available for quite some time. So you could check, what is common practice among distro packagers. F.e. on my box ( OpenSusSE 12.2 ) it is simply not part of qwt6-devel- doc. But the OpenSuSE package maintainer seems in general not being aware of these Qt specific files as the installation of the feature files is also broken. But the rest of the docs can be found below /usr/share/doc/packages/qwt6- devel-doc and IMO this is where I would expect to find qwt.qch as well. Maybe other distros can give you a better hint. > Q2: And would/could there be some way to have 3rd-party QCH files > automatically added to Qt Assistant, Creator & Co. on installation, to > spare the user the additional manual step? To me one of the most error prone things is loading 3rd party plugins to the creator. This has mostly to do with binary incompatibilities between the libraries used for development and the one used by the Creator ( Assistant is less bad as being built together with Qt libs ) , but the fact, that plugins are loaded "automatically" from some directories is part of the problem. Coming from having experienced maximal user frustration with this approach I wouldn't recommend to establish such an automatism. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Charts poor dynamic/resolution with OpenGL
On Wed, 09 Nov 2016 09:04:23 +, Miikka Heikkinen wrote: Hi Mikka, > I’m Qt Charts maintainer. It is true that Charts have been on back > burner for a good while now, as I’ve been assigned to other tasks, but > it’s not abandoned by any means. Maybe you could shed some light on the future of this module: what has happened is, that Qt project has started a new module, that naturally was/is behind 3rd party projects, that exist since many years. AFAIK the motivation to start this project was more a commercial driven decision than, that the existing solutions were not good enough. I'm doing the Qwt project for almost 18 years now and I'm fine if at some point it can be replaced by an official package. But to me Qt Charts looks like something that didn't work as a commercial idea and now rests more or less idle in the repositories ? Or if you don't intend to make it the best solution: what is the motivation of the Qt project in having this module at all, when there are several free and actively maintained chart packages around ? ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Charts poor dynamic/resolution with OpenGL
On Tue, 08 Nov 2016 13:30:45 +0100, Jeandet Alexis wrote: > Our goal is to improve QtCharts to be able to use it in our scientific > softwares. So we need to improve the current dynamic with OpenGL and/or > improve performances of non OpenGL plots. Have you ever considered to use a 3rd party library like Qwt or QCustomPlot. Both packages are available since years and focus on scientific plots. Being the maintainer of the Qwt package I'm some sort of a biased, but my impression is, that the Qt Chart package has never reached a state being even close to other solutions. And as I never saw anyone responding to related questions on the mailing lists it also does not look like being a very actively maintained module. ciao, Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Revisiting high-DPI configuration options
On Wed, 20 Jul 2016 10:44:16 -0700, Thiago Macieira wrote: >> Why SVG support of QIcon can not cache rendered result? So re-rendering >> will be as fast as for PNGs. Or you are saying about app startup time? > > Startup. When using SVGs you have to load/parse it into QSvgRenderer and later it needs to be replayed via QPainter in the size you need. While the second step can't be avoided at runtime, it is possible to convert SVGs into something, that can be loaded significantly faster, at compile time. I'm using an implementation based on this class: http:// qwt.sourceforge.net/class_qwt_graphic.html. This is a record/replay device for QPainter commands - like QPicture, but suitable for vector graphics. I added load/save methods ( not yet in SVN ) and then the compiler itself is 20 lines of code only. When using such a concept with Qt Quick, better don't use standard Image classes as they are designed for raster graphics. Better write your own type of control for it - at least this is what I did. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
