Re: [Development] How to speed up QML for KDE5 without QML compiler

[Leslie Zhai]

在 2015年09月16日 17:51, Konstantin Tokarev 写道:
> 16.09.2015, 07:04, "Leslie Zhai" :
>> Hi great Qt and KDE developers,
>>
>> I like QML, it is high speed development language, easy to create candy
>> UI and not difficult to debug. KDE4 began to use it in some projects,
>> for example, KScreen`s kcm module, it used QML to take place of
>> traditional QWidget. and KDE5, it is full of QML, for example, kwin`s
>> tabbox, plasma-desktop and plasma-workspace`s applet, sddm, etc.
>>
>> For a new PC, there is no sharp difference between QML and QWidget, but
>> in a very very old PC, how old? about 7 years ago, QML is very slow! and
>> it needs to close all effects for KDE5, even that when clicked, for
>> example, calendar applet, it hang about 3+ seconds to showPopup.
>>
>> There is commercial QML compiler, a very small example tried to use it
>> https://github.com/AOSC-Dev/AOSC-VersionHelper2
>> But is it suitable for huge projects just like KDE5 if bought a
>> commercial license? because not all KF5 components follow the Qt Quick
>> Compiler`s resource.qrc way, so is it able to compile? for example,
>> kickoff applet (the start menu of KDE5).
>>
>> --
>> Regards,
>> Leslie Zhai - a KDE developer
> You might want to use generic approach working for any scripting language:
> 1) profile; 2) find bottlenecks; 3) rewrite them in "fast" language (C++ here)
>
> As for rewrite from QML to C++:
>
> 1. Try to move all business logic and computations to C++ classes, make this 
> code
> available to QML via QObject-derived classes (see "Defining QML Types from 
> C++"
> document and also docs for qmlRegisterType and qmlRegisterSingletonType)
>
> 2. Identify reusable QML items and rewrite them in C++ using class derived
> from QQuickItem. See "Writing QML Extensions with C++" document.
Yes, plasma-framework 
https://projects.kde.org/projects/frameworks/plasma-framework/repository 
developed QML Extension Plugin and easy-to-import in QML example 
https://github.com/xiangzhai/plasma-helloworld

But such as plasma-workspace`s krunner 
https://projects.kde.org/projects/kde/workspace/plasma-workspace/repository/revisions/master/show/krunner
 
and kwin`s tabbox 
https://projects.kde.org/projects/kde/workspace/kwin/repository/revisions/master/show/tabbox
I prefer to directly operate QML object in C++ via objectName too, so in 
this situation, it is not able to use QML Compiler, right? then is it 
better to re-architecture some KDE5 projects to follow the QML Extension 
Plugin way?

And is there some benchmark to compare before and after compiled with 
QML Compiler for small and big project?


>
> Another possible cause of sluggish performance is suboptimal usage of OpenGL.
> Try to use best drivers available for your graphics hardware. You might also
> consider using OpenGL profiling tools.
Thanks for your advice ;-) I will fallback to light DE when OpenGL 
profiling score is low.


>

-- 
Leslie Zhai

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Enhancement to QIODevice?

[Thiago Macieira]

On Wednesday 16 September 2015 13:13:01 Andrzej Ostruszka wrote:
> On 09/16/2015 08:57 AM, Thiago Macieira wrote:
> >>> You could use peek() to search the buffer, then read() exactly as much
> >>> as
> >>> you really need.
> >> 
> >> I understand that we are talking about
> >> QIODevicePrivateLinearBuffer::peek() here.
> > 
> > No, I meant QIODevice::peek()
> 
> First of all - I do not claim that I have mastered Qt internals!
> So everything below you should take with a grain of salt :)

No problem. I don't remember the internals of peek(), but I do remember it 
trying to unread each character, one by one. Or was that 
QProcess::setReadChannel...?

> QIODevice::peek() is implemented in terms of QIODevice::read() (which
> then uses QIODevicePrivate::read() which does the memcpy()) and later
> putting it back.  Pretty convoluted but it really does not matter - I
> just assumed the simpler case of direct peek into the buffer.

Well, yeah, it needs to read at least one from the lower device into the 
QIODevice buffer. It will then copy the data again to your buffer. There's no 
way to avoid the double copy, unless device implementation (QSerialPort?) 
already read into the QIODevice buffer. Please talk to Alex Trotsenko to 
optimise this.

But canReadLine() needs to do something similar already. If the data isn't 
buffered yet, it needs to call readData() to copy into the buffer first, then 
read it.

> Here I must say that I don't understand.  Let me rephrase what I've said
> earlier.  Suppose that there is some data in buffer and I want to know
> if delimiter is in it.  Without direct access to this buffer memory I
> can only:
> 1. copy (by peeking()) it to some other place (possibly the final output
> buffer)
> 2. search for delimiter in my copy
> 3. if found: drop "number of bytes to delimiter" from buffer

Right.

Note that this is already an improvement over status quo: right now, you need 
to read() everything and buffer the data that you didn't need just yet.

> What I'm saying is that in successful case (when delimiter is found)
> this sequence is optimal.  However, in case when there is no delimiter
> yet in the buffer, operation 1 is wasted (not really needed).  And I
> don't see how to avoid it without allowing user to search in the
> internal buffer.

I see.

> Possible ways to allow for searching in this buffer are (I'm shortening
> names here):
> A. Add optional param to canReadLine() readLine() (for QIODP or maybe
> even QIOD)

Not to those functions. It would be a new set of them.

> B. Add this QIODPLB::countTo() functionality (which does not break or
> interfere with anything)
> C. Add QIODPLB::data() function to buffer which will return "first" (I'm
> talking in terms of QIODPLB implementation)

Returning access to the internal buffer is something to consider. It would 
allow for one memcpy fewer of the data. But it's not something that we can 
trivially do.

> As for C.  This is another solution - which also does not interfere with
> anything.  The amount of data is already available via size().
> Then any kind of "packet" termination can be implemented (not just by
> single char) on top of it.  Value returned by this QIODPLB::data() is
> only invalidated by explicit user reading so this would be pretty safe
> too and its only one line of code.
> 
> So what do you think?

The internal buffer is chunked, so the delimiter may not be in the first 
buffer. 
And I don't want to provide access to the internal buffers without a lot of 
thought to design, since after that it becomes ABI and we will have less 
freedom to improve.

QIODevice needs a complete redesign to support zero-copy. The current API 
created in Qt 4 (readData(), writeData(), etc.) is way too limited. The 
problem is that there's no way to do that without a major break in 
compatibility (so, Qt 6) and spending a *lot* of time fixing all the QIODevice 
subclasses (QBuffer, QFileDevice, QAbstractSocket, QProcess, QNetworkReply, 
QSerialPort, plus all the non-Qt code).

> > I think there are easier ways to do this, so I don't think it makes sense
> > to accept this suggestion.
> 
> Yes one can peek() at buffer but as I've tried to state this approach
> has some drawbacks (from performance point of view).  I can also
> understand that maintainers are worried about growing complexity and
> maintenance burden but honestly I don't see any growth in these from
> options B and C above.  These are internal, no testing for them is
> needed, they don't interfere with any other functionality etc.

I think you can help a lot by fixing some of the inefficiencies in peek(). That 
should help you quite a bit already. It won't be ideal, but it will be better. 
Or instead open the device in unbuffered mode and buffer yourself.

I understand the value of countTo(), but it can spiral out of control really 
quickly. After we add the one containing a single byte delimiter, we'll get 
people asking for:
 - string searching (like CRLF)
 - regular expres

Re: [Development] Adding Microsoft-licensed library in Qt Multimedia

[Thiago Macieira]

On Wednesday 16 September 2015 15:59:25 Lopes Yoann wrote:
> >> iii. Distribution Restrictions.  You may not
> >> ·   modify or distribute the source code of any Distributable Code so
> >> that any part of it becomes subject to an Excluded License.  An Excluded
> >> License is one that requires, as a condition of use, modification or
> >> distribution, that ·   the code be disclosed or distributed in source
> >> code form; or
> >> ·   others have the right to modify it.
> >>
> >> 
> >>
> > ah, the good old ms. i think the express purpose of that clause is to
> > forbid usage in (l)gpl code, which means we would have to distribute at
> > least that plugin under BSD or proprietary only.
> 
> You might be right… in that case this is probably a no-go.

It is.

And even if it weren't for this reason, the licence of this code is not OSI-
approved and not compliant with the DFSG, so please don't import it into Qt.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding Microsoft-licensed library in Qt Multimedia

[Lopes Yoann]

> On 16 Sep 2015, at 17:18, Oswald Buddenhagen 
>  wrote:
> 
> On Wed, Sep 16, 2015 at 02:34:49PM +, Lopes Yoann wrote:
>> ·   for any Distributable Code having a filename extension of .lib, 
>> distribute only the results of running such Distributable Code through a 
>> linker with your application;
>> 
> that may mean that we cannot distribute static binaries of that plugin,
> as that would imply shipping the helper .lib. that is, unless we employ
> ms lib's ability to link multiple static libs into a single static lib.
> sounds like work. ^^
> 
> or it may be irrelevant, because ms is not distributing a .lib in the
> first place …
Yes I think that’s irrelevant, in this case the Distributable Code is only c++ 
code.


>> iii. Distribution Restrictions.  You may not
>> ·   modify or distribute the source code of any Distributable Code so that 
>> any part of it becomes subject to an Excluded License.  An Excluded License 
>> is one that requires, as a condition of use, modification or distribution, 
>> that
>> ·   the code be disclosed or distributed in source code form; or
>> ·   others have the right to modify it.
>> 
> ah, the good old ms. i think the express purpose of that clause is to
> forbid usage in (l)gpl code, which means we would have to distribute at
> least that plugin under BSD or proprietary only.
You might be right… in that case this is probably a no-go.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Requesting New Repository - QtZeroConf

[Tobias Hunger]

Hi Thiago,

On Thu, Sep 10, 2015 at 5:47 PM, Thiago Macieira
 wrote:
> I don't know any project implementing LLMNR outside of Windows. It's clearly
> dead in terms of further adoption and mDNS has won. So I don't think we need
> to provide it for cross-platform interoperability. I'd say we provide mDNS for
> that. In addition, we may provide some other IoT protocols currently in
> development.

Systemd supports LLMNR and uses it to address containers it starts.

References:
http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
https://lwn.net/Articles/647634/

Best Regards,
Tobias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebEngine unbundled of third-party libraries on Linux

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 11 September 2015 19:26:22 Allan Sandfeld Jensen wrote:
[snip]
> > [Exactly one month later...]
> > 
> > I'll try to check this during the weekend. I'm terribly sorry for not
> > doing
> > it sooner, but life gets in the middle too much lately :-/

As it happened again, I'm trying to catch up now.

I failed to see relevant changes between 5.5 and 5.6 in the qtwebengine 
submodule git repo. Maybe I should look somewhere else?

[snip]
> Btw. If you know the people packaging Chromium, you could point them my way,
> we could probably share patches.

Not really, only thing I know is that their mailing list is

 https://lists.alioth.debian.org/mailman/listinfo/pkg-chromium-maint

and the git repository is

 http://anonscm.debian.org/cgit/pkg-chromium/pkg-chromium.git

Check for patches in debian/patches subdir.

We used to have a patch tracker but sadly it's not working anymore :(

-- 
http://xkcd.com/162/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding Microsoft-licensed library in Qt Multimedia

[Oswald Buddenhagen]

On Wed, Sep 16, 2015 at 02:34:49PM +, Lopes Yoann wrote:
> In order to improve and add missing features in the DirectShow Qt Multimedia 
> backend, I’d like to include a third-party library in Qt, namely, the 
> DirectShow Base Classes Library [1]. See link [2] for the patch adding it in 
> Qt Multimedia.
> 
> I’m just not sure about the legal part. This library is only made available 
> by Microsoft as source code in the Windows SDK samples. As such, it's covered 
> by the Windows SDK End-User License Agreement. Here's the relevant part of it:
> 

> ·   for any Distributable Code having a filename extension of .lib, 
> distribute only the results of running such Distributable Code through a 
> linker with your application;
>
that may mean that we cannot distribute static binaries of that plugin,
as that would imply shipping the helper .lib. that is, unless we employ
ms lib's ability to link multiple static libs into a single static lib.
sounds like work. ^^

or it may be irrelevant, because ms is not distributing a .lib in the
first place ...

> iii. Distribution Restrictions.  You may not
> ·   modify or distribute the source code of any Distributable Code so that 
> any part of it becomes subject to an Excluded License.  An Excluded License 
> is one that requires, as a condition of use, modification or distribution, 
> that
> ·   the code be disclosed or distributed in source code form; or
> ·   others have the right to modify it.
> 
ah, the good old ms. i think the express purpose of that clause is to
forbid usage in (l)gpl code, which means we would have to distribute at
least that plugin under BSD or proprietary only.

IANAL, etc. pp.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Adding Microsoft-licensed library in Qt Multimedia

[Lopes Yoann]

Hello all,

In order to improve and add missing features in the DirectShow Qt Multimedia 
backend, I’d like to include a third-party library in Qt, namely, the 
DirectShow Base Classes Library [1]. See link [2] for the patch adding it in Qt 
Multimedia.

I’m just not sure about the legal part. This library is only made available by 
Microsoft as source code in the Windows SDK samples. As such, it's covered by 
the Windows SDK End-User License Agreement. Here's the relevant part of it:

a.   Distributable Code.  The software contains code that you are permitted to 
distribute in programs you develop if you comply with the terms below.
i.   Right to Use and Distribute.  The code and text files listed below are 
“Distributable Code.”
...
·   Sample Code.  You may modify, copy, and distribute the source and object 
code form of code marked as “sample.”
...
ii.  Distribution Requirements.  For any Distributable Code you distribute, you 
must
·   add significant primary functionality to it in your programs;
·   for any Distributable Code having a filename extension of .lib, distribute 
only the results of running such Distributable Code through a linker with your 
application;
·   require distributors and external end users to agree to terms that protect 
it at least as much as this agreement;
·   display your valid copyright notice on your programs;
·   indemnify, defend, and hold harmless Microsoft from any claims, including 
attorneys’ fees, related to the distribution or use of your programs.
iii. Distribution Restrictions.  You may not
·   alter any copyright, trademark or patent notice in the Distributable Code;
·   use Microsoft’s trademarks in your programs’ names or in a way that 
suggests your programs come from or are endorsed by Microsoft;
·   distribute Distributable Code to run on a platform other than the Windows 
platform;
·   include Distributable Code in malicious, deceptive or unlawful programs; or
·   modify or distribute the source code of any Distributable Code so that any 
part of it becomes subject to an Excluded License.  An Excluded License is one 
that requires, as a condition of use, modification or distribution, that
·   the code be disclosed or distributed in source code form; or
·   others have the right to modify it.

Does anyone have an idea about the legality of including this in Qt?
And if it's fine to include it, what should be in the license notice alongside 
the code?

[1]: 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd375456(v=vs.85).aspx
[2]: https://codereview.qt-project.org/#/c/125865

—
Yoann
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Enhancement to QIODevice?

[Mark Gaiser]

On Wed, Sep 16, 2015 at 1:13 PM, Andrzej Ostruszka <
andrzej.ostrus...@gmail.com> wrote:

> On 09/16/2015 08:57 AM, Thiago Macieira wrote:
> >>> You could use peek() to search the buffer, then read() exactly as much
> as
> >>> you really need.
> >>
> >> I understand that we are talking about
> >> QIODevicePrivateLinearBuffer::peek() here.
> >
> > No, I meant QIODevice::peek()
>
> First of all - I do not claim that I have mastered Qt internals!
> So everything below you should take with a grain of salt :)
>
> QIODevice::peek() is implemented in terms of QIODevice::read() (which
> then uses QIODevicePrivate::read() which does the memcpy()) and later
> putting it back.  Pretty convoluted but it really does not matter - I
> just assumed the simpler case of direct peek into the buffer.
>
> >> In your approach I'd be copying data twice, but I can eliminate one with
> >> peek()ing
> >> directly to the output buffer and later skip()ping in successful case.
> >> However in case
> >> when delimiter is not yet available I'd have unnecessary copying.
> >
> > Then please provide a patch that avoids the unnecessary second copy when
> the
> > read() destination is a null pointer.
>
> Here I must say that I don't understand.  Let me rephrase what I've said
> earlier.  Suppose that there is some data in buffer and I want to know
> if delimiter is in it.  Without direct access to this buffer memory I
> can only:
> 1. copy (by peeking()) it to some other place (possibly the final output
> buffer)
> 2. search for delimiter in my copy
> 3. if found: drop "number of bytes to delimiter" from buffer
>
> What I'm saying is that in successful case (when delimiter is found)
> this sequence is optimal.  However, in case when there is no delimiter
> yet in the buffer, operation 1 is wasted (not really needed).  And I
> don't see how to avoid it without allowing user to search in the
> internal buffer.
>
> Possible ways to allow for searching in this buffer are (I'm shortening
> names here):
> A. Add optional param to canReadLine() readLine() (for QIODP or maybe
> even QIOD)
> B. Add this QIODPLB::countTo() functionality (which does not break or
> interfere with anything)
> C. Add QIODPLB::data() function to buffer which will return "first" (I'm
> talking in terms of QIODPLB implementation)
> D. ???
>
> As for C.  This is another solution - which also does not interfere with
> anything.  The amount of data is already available via size().
> Then any kind of "packet" termination can be implemented (not just by
> single char) on top of it.  Value returned by this QIODPLB::data() is
> only invalidated by explicit user reading so this would be pretty safe
> too and its only one line of code.
>
> So what do you think?
>
> >> And while peek()ing I'd have to use the min(max size of my output
> >> buffer, size())
> >> which would mean that I'd be copying "overlapping" parts more than once.
> >
> > I didn't understand this.
>
> What I wanted to say is that:
> - in operation 1 above the number of bytes to peek need to be specified
> - the only reasonable choice - without using some application specific
> heuristic - is the amount of bytes already available (lets forget for a
> moment possible constrains of my output buffer size)
>
> Then in situation when in buffer is more then just one "line" available
> I would be copying parts of data after first delimiter in order to later
> put them back and read them again on next data arrival.
>
> > I think there are easier ways to do this, so I don't think it makes
> sense to
> > accept this suggestion.
>
> Yes one can peek() at buffer but as I've tried to state this approach
> has some drawbacks (from performance point of view).  I can also
> understand that maintainers are worried about growing complexity and
> maintenance burden but honestly I don't see any growth in these from
> options B and C above.  These are internal, no testing for them is
> needed, they don't interfere with any other functionality etc.
>
> So Your Honour, what is the verdict? ;)
>
> Regards
> Andrzej
>

I'm curious, why is QIODevicePrivate::peek (both versions of it) doing:
- calling read (which resizes the internal buffer to whatever is left after
reading). It does this via memmove.
- then it restores the buffer to it's original by taking the current buffer
and appending what was read. It does this via memcpy.

Rather then doing:
- call QIODevicePrivateLinearBuffer::peek (on the buffer object in
QIODevicePrivate) and leave the internal buffer untouched? The function is
just sitting there [1], but it isn't being used by either
QIODevice(Private)::peek function.

It would avoid fiddling with the internal buffer and just copy (a part of)
the internal buffer to the user. That is what peek should do according to
the documentation.
Peek would the not call QIODevice::read anymore.

Performance wise, this likely makes peek faster (no more read call, no more
memmove, no more memcpy on the internal buffer), memory wise there still is
th

Re: [Development] How to speed up QML for KDE5 without QML compiler

[Ulf Hermann]

> Can you explain that a little more.
> Loaders trade startup delay for runtime cost.
> What are the units of measure for runtime cost?

Runtime cost is measured in CPU time spent while interacting with the 
application. In some places, such as when scrolling, increasing the CPU time 
spent can be problematic.

If you don't use a loader all the items you need are created when the 
application starts. That takes some time, but later when you use them they are 
already there and it takes very little time to show them or otherwise interact 
with them.

If you use a loader, the application starts more quickly but the items are 
created while you interact with it. This can lead to some unattractive effects 
like unfinished UI elements being visible and the frame rate dropping.

You can try some funny adventures I had with that by loading a large trace into 
the QML profiler, expanding all the categories and then comparing the vertical 
scrolling between
a, QtCreator 3.3
b, https://codereview.qt-project.org/#/c/103618/ and 
https://codereview.qt-project.org/#/c/103617/
c, https://codereview.qt-project.org/#/c/103648
d, QtCreator 3.5

I ended up writing a "SynchronousReloader" in order to be able to use 
asynchronous Loaders without having blank labels being visible during 
scrolling. However, I'm still not sure if the added CPU time spent on loading 
them after expanding the categories (and potentially during scrolling) is 
actually worth the reduced "startup" time when loading a trace.

-- 
Ulf Hermann
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to speed up QML for KDE5 without QML compiler

[m...@rpzdesign.com]

Ulf:

Can you explain that a little more.

Loaders trade startup delay for runtime cost.

What are the units of measure for runtime cost?

I am having trouble plotting in my mind how to plot the tradeoff.

As startup delay goes up, does runtime cost go down?

Thanks,

md

On 9/16/2015 5:15 AM, Ulf Hermann wrote:
> Hi,
>
> Use the QML profiler in Qt Creator to find out what exactly is slow. Use 
> loaders, but don't overuse them. Loaders trade startup delay for runtime 
> cost. You should decide what is worse depending on your application.
>

-- 
No spell checkers were harmed during the creation of this message.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to speed up QML for KDE5 without QML compiler

[Ulf Hermann]

Hi,

Use the QML profiler in Qt Creator to find out what exactly is slow. Use 
loaders, but don't overuse them. Loaders trade startup delay for runtime cost. 
You should decide what is worse depending on your application.

-- 
Ulf Hermann
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Enhancement to QIODevice?

[Andrzej Ostruszka]

On 09/16/2015 08:57 AM, Thiago Macieira wrote:
>>> You could use peek() to search the buffer, then read() exactly as much as
>>> you really need.
>>
>> I understand that we are talking about
>> QIODevicePrivateLinearBuffer::peek() here.
>
> No, I meant QIODevice::peek()

First of all - I do not claim that I have mastered Qt internals!
So everything below you should take with a grain of salt :)

QIODevice::peek() is implemented in terms of QIODevice::read() (which 
then uses QIODevicePrivate::read() which does the memcpy()) and later 
putting it back.  Pretty convoluted but it really does not matter - I 
just assumed the simpler case of direct peek into the buffer.

>> In your approach I'd be copying data twice, but I can eliminate one with
>> peek()ing
>> directly to the output buffer and later skip()ping in successful case.
>> However in case
>> when delimiter is not yet available I'd have unnecessary copying.
>
> Then please provide a patch that avoids the unnecessary second copy when the
> read() destination is a null pointer.

Here I must say that I don't understand.  Let me rephrase what I've said 
earlier.  Suppose that there is some data in buffer and I want to know 
if delimiter is in it.  Without direct access to this buffer memory I 
can only:
1. copy (by peeking()) it to some other place (possibly the final output 
buffer)
2. search for delimiter in my copy
3. if found: drop "number of bytes to delimiter" from buffer

What I'm saying is that in successful case (when delimiter is found) 
this sequence is optimal.  However, in case when there is no delimiter 
yet in the buffer, operation 1 is wasted (not really needed).  And I 
don't see how to avoid it without allowing user to search in the 
internal buffer.

Possible ways to allow for searching in this buffer are (I'm shortening 
names here):
A. Add optional param to canReadLine() readLine() (for QIODP or maybe 
even QIOD)
B. Add this QIODPLB::countTo() functionality (which does not break or 
interfere with anything)
C. Add QIODPLB::data() function to buffer which will return "first" (I'm 
talking in terms of QIODPLB implementation)
D. ???

As for C.  This is another solution - which also does not interfere with 
anything.  The amount of data is already available via size().
Then any kind of "packet" termination can be implemented (not just by 
single char) on top of it.  Value returned by this QIODPLB::data() is 
only invalidated by explicit user reading so this would be pretty safe 
too and its only one line of code.

So what do you think?

>> And while peek()ing I'd have to use the min(max size of my output
>> buffer, size())
>> which would mean that I'd be copying "overlapping" parts more than once.
>
> I didn't understand this.

What I wanted to say is that:
- in operation 1 above the number of bytes to peek need to be specified
- the only reasonable choice - without using some application specific 
heuristic - is the amount of bytes already available (lets forget for a 
moment possible constrains of my output buffer size)

Then in situation when in buffer is more then just one "line" available 
I would be copying parts of data after first delimiter in order to later 
put them back and read them again on next data arrival.

> I think there are easier ways to do this, so I don't think it makes sense to
> accept this suggestion.

Yes one can peek() at buffer but as I've tried to state this approach 
has some drawbacks (from performance point of view).  I can also 
understand that maintainers are worried about growing complexity and 
maintenance burden but honestly I don't see any growth in these from 
options B and C above.  These are internal, no testing for them is 
needed, they don't interfere with any other functionality etc.

So Your Honour, what is the verdict? ;)

Regards
Andrzej
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to speed up QML for KDE5 without QML compiler

[Robin Burchell]

On Wed, Sep 16, 2015, at 06:03 AM, Leslie Zhai wrote:
> For a new PC,  there is no sharp difference between QML and QWidget, but 
> in a very very old PC, how old? about 7 years ago, QML is very slow! and 
> it needs to close all effects for KDE5, even that when clicked, for 
> example, calendar applet, it hang about 3+ seconds to showPopup.

This may be an obvious statement, but QML's capabilities (like that of
any other software) are dependent on the hardware you run it on. The
slower the CPU/GPU, the less you can accomplish in the same amount of
wallclock time.

The key to good performance when using QML is to do the minimal amount
possible at any given time. This means:
* Not having useless wrapper items, e.g: Item { OtherThing { } } <- this
is creating an item to do absolutely nothing
* Having bindings be as simple as possible
* Aggressively delay loading of items (using Loader, make sure to keep
them in seperate source files too to minimize the amount of time spent
parsing)

All of these points are multiplied depending on how often you do them,
e.g. in a ListView's delegate, you construct a lot of delegates, so any
inefficiencies there will be multiplied by however many delegates you
create.

Keep in mind that the things you use to write your application matters
quite a bit, too. For example, QtQuickControls' Button is a lot more
complicated & heavy than something like Rectangle + MouseArea (this
example may not hold as relevant with QtQuickControls 2, I haven't
looked into it much).

You can take a look at https://github.com/sletta/qmlbench to get a sense
for how expensive different parts of QML are (and how many of certain
items you can create per frame, and such).

In addition to all that: I agree with what Konstantin said. Before
trying to fix performance, you first need to understand what's wrong
with it, which involves profiling and understanding the problem "under
the hood".

> There is commercial QML compiler, a very small example tried to use it 
> https://github.com/AOSC-Dev/AOSC-VersionHelper2
> But is it suitable for huge projects just like KDE5 if bought a 
> commercial license? because not all KF5 components follow the Qt Quick 
> Compiler`s resource.qrc way, so is it able to compile? for example, 
> kickoff applet (the start menu of KDE5).

Probably not. IIRC the compiler ties you to a particular Qt version: you
must use the same Qt version at runtime as you compiled the sources
with. So unless it was used as part of the distribution's build setup
(for instance) it probably wouldn't work at all.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to speed up QML for KDE5 without QML compiler

[Guenter Schwann]

On Wednesday 16 September 2015 12:03:38 Leslie Zhai wrote:
> Hi great Qt and KDE developers,
> 
> I like QML, it is high speed development language, easy to create candy
> UI and not difficult to debug. KDE4 began to use it in some projects,
> for example, KScreen`s kcm module, it used QML to take place of
> traditional QWidget. and KDE5, it is full of QML, for example, kwin`s
> tabbox, plasma-desktop and plasma-workspace`s applet, sddm, etc.
> 
> For a new PC,  there is no sharp difference between QML and QWidget, but
> in a very very old PC, how old? about 7 years ago, QML is very slow! and
> it needs to close all effects for KDE5, even that when clicked, for
> example, calendar applet, it hang about 3+ seconds to showPopup.
> 
> There is commercial QML compiler, a very small example tried to use it
> https://github.com/AOSC-Dev/AOSC-VersionHelper2
> But is it suitable for huge projects just like KDE5 if bought a
> commercial license? because not all KF5 components follow the Qt Quick
> Compiler`s resource.qrc way, so is it able to compile? for example,
> kickoff applet (the start menu of KDE5).

Hi,

One generic advise is to use the Loader item a lot. So only visible/needed 
items are created.
This helps a lot for the startup performance.

And in the Loader rather use the source instead of the sourceComponent 
property (or use the setSource() function). As the sourceComponent still 
parses all stuff (although the binding is the biggest time consumer usually).

It will make your code more complex. And of course has it's limits and might 
not be your biggest bottleneck. But usually helps a lot.

-- 
Guenter Schwann

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to speed up QML for KDE5 without QML compiler

[Konstantin Tokarev]

16.09.2015, 07:04, "Leslie Zhai" :
> Hi great Qt and KDE developers,
>
> I like QML, it is high speed development language, easy to create candy
> UI and not difficult to debug. KDE4 began to use it in some projects,
> for example, KScreen`s kcm module, it used QML to take place of
> traditional QWidget. and KDE5, it is full of QML, for example, kwin`s
> tabbox, plasma-desktop and plasma-workspace`s applet, sddm, etc.
>
> For a new PC, there is no sharp difference between QML and QWidget, but
> in a very very old PC, how old? about 7 years ago, QML is very slow! and
> it needs to close all effects for KDE5, even that when clicked, for
> example, calendar applet, it hang about 3+ seconds to showPopup.
>
> There is commercial QML compiler, a very small example tried to use it
> https://github.com/AOSC-Dev/AOSC-VersionHelper2
> But is it suitable for huge projects just like KDE5 if bought a
> commercial license? because not all KF5 components follow the Qt Quick
> Compiler`s resource.qrc way, so is it able to compile? for example,
> kickoff applet (the start menu of KDE5).
>
> --
> Regards,
> Leslie Zhai - a KDE developer

You might want to use generic approach working for any scripting language:
1) profile; 2) find bottlenecks; 3) rewrite them in "fast" language (C++ here)

As for rewrite from QML to C++:

1. Try to move all business logic and computations to C++ classes, make this 
code
available to QML via QObject-derived classes (see "Defining QML Types from C++"
document and also docs for qmlRegisterType and qmlRegisterSingletonType)

2. Identify reusable QML items and rewrite them in C++ using class derived
from QQuickItem. See "Writing QML Extensions with C++" document.

Another possible cause of sluggish performance is suboptimal usage of OpenGL.
Try to use best drivers available for your graphics hardware. You might also
consider using OpenGL profiling tools.

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Old platform-specific functions

[Jake Petroules]

> On Sep 15, 2015, at 9:07 PM, Sze Howe Koh  wrote:
> 
> Hi all,
> 
> There's a list of platform-specific functions from Qt 4:
> http://doc.qt.io/qt-5/exportedfunctions.html
> 
> It looks like most of these functions are now gone. The non-existing
> functions should be removed from the documentation, but 3 functions
> remain in the code base:
> 
> * qt_mac_secure_keyboard() is marked Q_DEAD_CODE_FROM_QT4_MAC (qlineedit.cpp)

Maybe introduce a new function in QPA, exposed through QtMac namespace in 
QtMacExtras?

> * qt_mac_set_dock_menu() is marked QT_DEPRECATED, and is slated for
> removal in Qt 6 (qmenu.h)

Replaced by QMenu::setAsDockMenu 
(http://doc.qt.io/qt-5/qmenu.html#setAsDockMenu 
)

> * qt_set_sequence_auto_mnemonic() is not marked as dead/deprecated in any way.

Maybe introduce a new function on QShortcut that takes an enum (Auto, On, Off)?

> 
> Should any of these be left in the documentation? (Note that
> qt_set_sequence_auto_mnemonic() is currently documented as a way to
> get non-standard behaviour on OS X:
> http://doc.qt.io/qt-5/qshortcut.html#details )
> 
> 
> Regards,
> Sze-Howe
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petroules at petroules.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development