[Development] i.MX6 zero copy video playback

[Thomas Senyk]

Hi,

I finally got around to polish and upstream zero copy video playback for the 
i.MX6.

The change:
https://codereview.qt-project.org/#change,76764

A video showcasing the functionality:
http://www.youtube.com/watch?v=pmxsWGhrrBQ


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

Re: [Development] i.MX6 zero copy video playback

[Thomas Senyk]

On Thursday, 13 February, 2014 9:16:43 Michal Lazo wrote:
> Do you use gstreamer 0.10 for video audio pipeline
> or android ?

gstreamer

> 
> Best
> 
> 
> On Wed, Feb 12, 2014 at 10:43 AM, Thomas Senyk
> 
> wrote:
> > Hi,
> > 
> > I finally got around to polish and upstream zero copy video playback for
> > the
> > i.MX6.
> > 
> > The change:
> > https://codereview.qt-project.org/#change,76764
> > 
> > A video showcasing the functionality:
> > http://www.youtube.com/watch?v=pmxsWGhrrBQ
> > 
> > 
> > Greets
> > Thomas
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] i.MX6 zero copy video playback

[Thomas Senyk]

On Thursday, 13 February, 2014 13:16:42 Michael Olbrich wrote:
> Hi,
> 
> On Wed, Feb 12, 2014 at 10:43:25AM +0100, Thomas Senyk wrote:
> > I finally got around to polish and upstream zero copy video playback for
> > the i.MX6.
> > 
> > The change:
> > https://codereview.qt-project.org/#change,76764
> > 
> > A video showcasing the functionality:
> > http://www.youtube.com/watch?v=pmxsWGhrrBQ
> 
> Nice. Are there any limitation regarding the input QVideoFrames? I've used
> glTexDirectVIVMap in the past, and I don't think that using it on malloc'ed
> memory ever worked for me.

never tried it on malloc'ed memory ... I think gstreamer somehow reserves them 
in a specific memory block.

So the answer is: I don't know :)

> 
> Regards,
> Michael

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

Re: [Development] Embedded (Linux) specific features

[Thomas Senyk]

On Sunday, 16 February, 2014 0:36:39 Laszlo Papp wrote:
> On Sat, Feb 15, 2014 at 8:45 PM, Pau Garcia i Quiles
> 
>  wrote:
> > On Sat, Feb 15, 2014 at 9:05 PM, Laszlo Papp  wrote:
> >> I wrote some C++ classes 1.5-2 years ago for some of the following
> >> features:
> >> 
> >> * GPIO
> >> * Eeprom
> >> * Power management
> >> * LED
> >> * Hardware Monitoring
> >> * DMA
> >> * Real Time Clock
> >> * I2C
> >> * SPI
> >> * etc.
> >> 
> >> Out of curiosity: is there anyone working on such classes in Qt? Would
> >> such features be welcome in Qt in general? If not, why not, if yes,
> >> where would they fit into the overall architecture?
> >> 
> >> It is not necessarily embedded Linux specific, but at least embedded.
> >> They might be useful on QNX, etc, but I cannot be sure. I would have a
> >> hard time suggesting place like QtEmbeddedExtras or so. I have no
> >> clear idea at this point.
> >> 
> >> These are generic features, and I only thought about bringing this
> >> topic up because I see customers and hobbyists reimplementing the
> >> same, e.g. for the raspberry pi.
> >> 
> >> Apologies if there are no interest at all for this.
> > 
> > I'm interested in almost all of the above, (and CAN bus communication)
> 
> I wrote a semi-good implementation about a bit more than one year ago,
> but currently I do not use it since I switched to a new project. Fwiw,
> no maintainer has been interested, so it did not go live (due to also
> my project switch):
> http://lists.qt-project.org/pipermail/development/2013-June/011243.html


I've no immediate need, but I'm pretty sure I'll stumble over one/all of them 
sooner then later.

+1 for playground project.

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

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

Re: [Development] i.MX6 zero copy video playback

[Thomas Senyk]

On Thursday, 27 February, 2014 17:57:43 Michael Olbrich wrote:
> Hi,
> 
> On Tue, Feb 18, 2014 at 10:18:36AM +0100, Thomas Senyk wrote:
> > On Thursday, 13 February, 2014 13:16:42 Michael Olbrich wrote:
> > > On Wed, Feb 12, 2014 at 10:43:25AM +0100, Thomas Senyk wrote:
> > > > I finally got around to polish and upstream zero copy video playback
> > > > for
> > > > the i.MX6.
> > > > 
> > > > The change:
> > > > https://codereview.qt-project.org/#change,76764
> > > > 
> > > > A video showcasing the functionality:
> > > > http://www.youtube.com/watch?v=pmxsWGhrrBQ
> > > 
> > > Nice. Are there any limitation regarding the input QVideoFrames? I've
> > > used
> > > glTexDirectVIVMap in the past, and I don't think that using it on
> > > malloc'ed
> > > memory ever worked for me.
> > 
> > never tried it on malloc'ed memory ... I think gstreamer somehow reserves
> > them in a specific memory block.
> > 
> > So the answer is: I don't know :)
> 
> So, I had some time to work with this. I found one limitation: the memory
> must be 64 Bytes aligned. Unfortunately I have no idea how this could be
> communicated upstream.
> I also found that the texture cache based on the virtual address is rather
> fragile. I've had several cases where different video frames had the same
> virtual address. I'm not sure how to fix this. Maybe some special meta data
> that can be used if provided or a special handle type?
> 
> Anyways, I've submitted some changes for review:
> 
> https://codereview.qt-project.org/#change,79447
> https://codereview.qt-project.org/#change,79448
> https://codereview.qt-project.org/#change,79449
> 
> Thomas, it would be great if you could test if this works for you.

Guess Andy was faster @ review :)

I very much like change 79447, I always though this should be solved better, 
but for some reason I never considered a config.test :)
just tested -> works for me!

@ 79448: where have you found video sources with all those formats?

@ 79449: yes, I fully agreed, but I don't have time to test right now.

Thanks
Thomas

> 
> Regards,
> Michael

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

Re: [Development] [Interest] Qt5.2.1+eglfs / WebKit2 running on i.MX6q ?

[Thomas Senyk]

On Wednesday, 26 February, 2014 12:51:30 BERTIN, NICOLAS wrote:
> Hey all,
> 
> I'm trying to get WebKit2 running on a Linux/i.MX6Q board (sabresd). I
> succeeded in building Qt5.2.1+eglfs and the WebKit1 based examples are
> running well.
> 
> Now, I'm trying to get WebKit2 running: the MiniBrowser example runs on
> the device, but only the navigation bar on top is functional, the webview
> area stays white and empty. The same issue occurs with the Flickrview
> example: only the thumbnails are shown...
> 
> I'd like to know if some you are experiencing the same kind of issues
> and/or have managed to make WebKit2 working on the same kind of platform?
> 
> Any advices to debug this problem are more than welcomed.
> 
> Thanks!

Looks like this issue is still present.
I can reproduce and on meta-fsl-arm mailing-list a couple of people can as 
well.

Has anyone investigated this so far?


(added dev as this seems to be a general problem on imx6 with webkit2 and 
Qt5.2.1)

Greets
Thomas

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

Re: [Development] [Interest] Qt5.2.1+eglfs / WebKit2 running on i.MX6q ?

[Thomas Senyk]

On Tuesday, 01 April, 2014 15:48:01 Michael Olbrich wrote:
> Hi,
> 
> On Tue, Apr 01, 2014 at 11:27:09AM +0200, Thomas Senyk wrote:
> > On Wednesday, 26 February, 2014 12:51:30 BERTIN, NICOLAS wrote:
> > > I'm trying to get WebKit2 running on a Linux/i.MX6Q board (sabresd). I
> > > succeeded in building Qt5.2.1+eglfs and the WebKit1 based examples are
> > > running well.
> > > 
> > > Now, I'm trying to get WebKit2 running: the MiniBrowser example runs on
> > > the device, but only the navigation bar on top is functional, the
> > > webview
> > > area stays white and empty. The same issue occurs with the Flickrview
> > > example: only the thumbnails are shown...
> > > 
> > > I'd like to know if some you are experiencing the same kind of issues
> > > and/or have managed to make WebKit2 working on the same kind of
> > > platform?
> > > 
> > > Any advices to debug this problem are more than welcomed.
> > > 
> > > Thanks!
> > 
> > Looks like this issue is still present.
> > I can reproduce and on meta-fsl-arm mailing-list a couple of people can as
> > well.
> > 
> > Has anyone investigated this so far?
> > 
> > 
> > (added dev as this seems to be a general problem on imx6 with webkit2 and
> > Qt5.2.1)
> 
> This is not imx6 specific. WebKit2 works with out of process rendering. I
> don't think there is any API eglfs could use to share the textures between
> the processes. Something like wayland is needed for that.

Actually your right. It has nothing to do with eglfs.

Isn't webkit2 sharing it's tiles with shm?
At least that's how it used to be :) .. because: it used to work with eglfs 
and your absolutely right, there is no way to share textures with a egl/fb 
setup.


The possible points of failure I see:
 - shm-setup
 - the filling (/rendering) of the shm
 - the take-out (/texture-upload) on gui side 


> 
> I've heard some rumors about wayland support for the binary vivante
> drivers, but I've not seen it anywhere.

I've checked that, same issue: webkit2-rendering is white for qt-wayland-
clients!

> 
> Wayland + Etnaviv (the open source driver for vivante GPUs) is probably the
> way to go. But that's currently in the 'some demos are working' stage[1].
> It's not really usable yet.
> 
> Regards,
> Michael
> 
> [1] https://plus.google.com/105928421692264581950/posts/2U7o9agHZ8z

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

Re: [Development] QtQuick QtCS Sessions

[Thomas Senyk]

On Friday, 13 June, 2014 23:07:08 Alan Alpert wrote:
> Here are the results and brief summaries of the 3 QtQuick related
> sessions, where we came up with some suggested new properties and
> types for QtQuick.
> 
> Touch and Gestures:
> http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCS14TouchAnd
> Gestures
> 
> No real solution other than handling Mouse, Touch, and Gestures
> (system gestures, no gesture manager). Also looking into new grab
> transfer mechanisms in QtQuick, such as a MouseArea.priority property
> for automatic transfer.
> 
> QtQuick:
> http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCS14QtQuick
> 
> Proposed new module, QtQmlGui (working title), which exposes non-core
> stuff to QML but can be shared between QtQuick and other modules (like
> Qt3D). Proposed new types, PolarPositioner, MouseRegion,
> TextContainer.
> 
> Declarative QML:
> http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCs14MoreDecl
> arative
> 
> Proposed new property, deferredLoading, on Item, to solve the less
> dynamic uses of Loader. Proposed new element, StateChange, to allow
> more declarative state changing. Big solutions of pull bindings and a
> pragma strictly-declarative are a lot of work, unlikely to occur soon.

How is "Translation" "DONE"?

Just to make sure we talk about the same thing:

https://bugreports.qt-project.org/browse/QTBUG-15602

Affects version should be "all" I guess .. this is (was?) the same case for all 
Qt versions and also QQuickView (quick2)

That's not solved .. is it?

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

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

Re: [Development] Setup QT creator for developing QT apps on wandboard-Error

[Thomas Senyk]

On Tuesday, 29 July, 2014 17:33:26 Christian Gagneraud wrote:
> On 29/07/2014 4:46 p.m., Nilesh Kokane wrote:
> > Hello ,
> > 
> > 
> > referring to
> > http://wiki.wandboard.org/index.php/Setup_QT_creator_for_developing_QT_app
> > s_on_wandboard#Build_and_Deploy_application_in_QT_Creator
> [...]
> 
> > 2)The second error is that even a simple default Qt console app program
> > is generating the ld error as follows.But native compiled version gives
> > a success.
> 
> [...]
> 
> > collect2: error: ld returned 1 exit status
> > make: *** [untitled6] Error 1
> > 17:40:35: The process "/usr/bin/make" exited with code 2.
> > Error while building/deploying project untitled6 (kit: i.mx6)
> > When executing step 'Make'
> > 17:40:35: Elapsed time: 00:01.
> 
> You might be better off pointing your linker to your sysroot instead of
> the Yocto managed Qt build directory, aren't all your libs inside your
> sysroot? You can check for that with this command:
> $ find
> /home/minda/bin/fsl-community-bsp/build/tmp/sysroots/wandboard-solo
> -name libicui18n.so.51 -o -name libz.so.1
> 
> What I don't understand in your case, is why the documentation tells you
> that you need meta-qt5 on one hand, and then tells you to manually
> cross-compile Qt5 just to setup QtCreator? According to your logs, you
> seem to use the yocto one anyway.

and mixing those two might not work anyway .. if you set --sysroot you can't 
have another Qt version already installed "there" 
(mixed headers => wrong symbols)

Also, if you want to use the meta-qt5 version you have to go the sdk (e.g. 
meta-toolchain-qt5) way, because it won't be that easy to use the 
tmp/.../qmake without some/a lot manually tweaking.

> 
> What does this command gives?
> $ sh -x ./qtcreator.sh
> 
> Maybe you still have a typo somewhere in your script.
> 
> Have you tried the "bitbake meta-toolchain-qt5" command?
> 
> Chris
> 
> > Can you please let me know if some steps are erroneous or missing.
> > 
> > Thanks
> > Nilesh Kokane
> > 
> > 
> > 
> > “The contents of this e-mail message and any attachments are
> > confidential and are intended solely for addressee. The information may
> > also be legally privileged. This transmission is sent in trust, for the
> > sole purpose of delivery to the intended recipient. If you have received
> > this transmission in error, any use, reproduction or dissemination of
> > this transmission is strictly prohibited. If you are not the intended
> > recipient, please immediately notify the sender by reply e-mail or phone
> > and delete this message and its attachments, if any.”
> > 
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] bitbake meta-toolchain error

[thomas . senyk]

EGL "thinks" (as in defines) it's a framebuffer build, Qt tries to build the 
XCB plugin .. shouldn't happen when removing x11 from distro_features.

Have you 'bitbake'ed before adding DISTRO_FREATURES_remove ... ?
If so consider to start over  with a fresh build because it might be a bit 
hard to get rid of all X11 traces.

You should go into meta-qt5, remove all "-silent" ... no clue why a managed 
build system would want to have "-silent" ..

If the errors persists also add the log for configure.


On Friday, August 01, 2014 02:49:55 PM Nilesh Kokane wrote:
> Hello,
> 
> 
> 
> I followed
> http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
> (newly added)
> 
> 
> The DISTRO_FEATURES_remove = "x11 wayland" is removed from the local.conf
> 
> 
> And after giving the bitbake core-image-minimal I'm logged with the errors
> as posted on pastebin http://pastebin.com/hsMhT9f8
> 
> 
> 
> 
> ERROR: Function failed: do_compile (log file is located at
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369) ERROR: Logfile of
> failure stored in:
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369
> 
> 
> 
> ERROR: Task 655
> (/home/minda/bin/fsl-community-bsp/sources/meta-qt5/recipes-qt/qt5/
> qtbase_5.2.1.bb, do_compile) failed with exit code '1'
> 
> 
> 
> 
> 
> can anyone suggest.

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

Re: [Development] Why is libxcb needed if GUI is disabled in build?

[Thomas Senyk]

On Friday, 29 August, 2014 7:09:55 Rutledge Shawn wrote:
> libX11 also ends up being linked into the eglfs platform plugin.  Even when
> configured with -no-xcb. 

There is a xcb "backend" (eglfshooks) for X11 .. maybe they have been selected 
for some reason?

> I must be missing something, otherwise how could
> any of the non-X11 embedded or Raspberry Pi stuff work…  Of course you can
> build on a machine that doesn't have the libs or headers available; I got
> that to work once. ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Help needed to test Ministro 10.3, needed for Qt 5.4!

[Thomas Senyk]

That's a real shame!

Just to clarify / for the record, is the following a result of 
MODE_WORLD_READABLE not working any more:

D/AndroidRuntime( 9159): Shutting down VM
E/AndroidRuntime( 9159): FATAL EXCEPTION: main
E/AndroidRuntime( 9159): Process: org.qtproject.example.foo, PID: 9159
E/AndroidRuntime( 9159): java.lang.UnsatisfiedLinkError: JNI_ERR 
returned from JNI_OnLoad in 
"/data/app/org.qtproject.example.foo-1/lib/arm/foo.so"
E/AndroidRuntime( 9159):at 
java.lang.Runtime.loadLibrary(Runtime.java:371)
E/AndroidRuntime( 9159):at java.lang.System.loadLibrary(System.java:989)
E/AndroidRuntime( 9159):at 
org.qtproject.qt5.android.bindings.QtActivity.loadApplication(QtActivity.java:252)
E/AndroidRuntime( 9159):at 
org.qtproject.qt5.android.bindings.QtActivity.access$400(QtActivity.java:94)

... or is it (as I first though) about a the deployment folder mismatch?
(within the apk it's lib/armeabi-v7a, but the device looks for it in 
lib/arm/)


Greets
Thomas


On 11/26/2014 07:08 PM, Harri Pasanen wrote:
> Hmm... looking at the issue it seems to me that it is not going to be
> fixed, it is an intentional change.   They are tightening the platform
> from security point of view, and this change is similar to change that
> made removable SD cards much less useful in KitKat:
> https://plus.google.com/+TodLiebeck/posts/gjnmuaDM8sn
>
> http://developer.android.com/reference/android/content/Context.html#MODE_WORLD_READABLE
> says it has been deprecated since API level 17, so I doubt they'll bring
> it back.
>
> Ministro has had a good run, but unless I'm mistaken this basically
> kills it?
>
> Harri
>
>
> On 26/11/2014 13:28, Cristian Adam wrote:
>>
>> Please "star" the android issue so that Google developers understand
>> the severity of the problem.
>>
>> It's not like only six people are affected by this.
>>
>> Cheers,
>> Cristian.
>>
>> On 26 Nov 2014 12:45, "BogDan" > > wrote:
>>
>> Hello folks,
>>
>> I have some bad news about Ministro on Android 5.0. Due to a bug
>> https://code.google.com/p/android/issues/detail?id=79478 introduced by
>> Google in Android 5.0 final release apps that are using Ministro
>> are not working anymore, on Android L preview it worked just fine.
>> I hope in the next Android version Google will fix this problem.
>>
>> New stuff added to Ministro 10.
>> - application startup up speed improvement, I've cuted +150ms from the
>> time that your application needs to wait for Ministro's response, now
>> your application waits 2-4ms (of course if Ministro doesn't need to
>> download/extract anything).
>> - extract Qt 5.4 QuickControls style info
>> - speed up the theme extraction (now it needs 2/3 of the previous
>> time).
>> - extract InsetDrawable. On Android 4.4.4 it seems this Drawable is
>> used and will crash QWidget based apps if is not extracted.
>>
>> New stuff added to 10.1
>>  - bumped MINISTRO_MAX_API_LEVEL
>>
>> New stuff added to 10.3
>>  - for more exceptions on Android 5.0
>>  - extract default palette & fonts, needed by Qt 5.4
>>  - extract some Android 5.0 specific look and style info.
>>
>> What happen with 10.2?
>>  - I bumped the version to 10.3 by mistake and I pushed it, so
>> there was no 10.2 :).
>>
>> How to test it:
>> - make sure the previous version is installed and your apps are
>> using it.
>> - install over the previous version ($ adb install -r Ministro\
>> II\ v10.3.apk).
>>   * Ministro will extract again *ONCE* the style.
>>   * Trying your existing apps should *NOT* trigger any new downloads.
>> - after you test your applications with Ministro installed on top of
>> previous Ministro version, please test in on a clean installation. So,
>> go to settings -> apps and remove Ministro, then install it again ($
>> adb install Ministro\ II\ v10.3.apk).
>>   * Ministro should extract style info and certificates and it should
>> download again all needed libs.
>>   * Your application should work without any recompilation.
>>
>>
>> Please download and test Ministro from here:
>> https://files.kde.org/necessitas/installer/test/Ministro%20II%20v10.3.apk
>>
>> Thank you!
>>
>> Cheers,
>> BogDan.
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org 
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>>
>> ___
>> Necessitas-devel mailing list
>> necessitas-de...@kde.org
>> https://mail.kde.org/mailman/listinfo/necessitas-devel
>
>
>
> ___
> Necessitas-devel mailing list
> necessitas-de...@kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel
>

___
Development mailin

[Development] QSceneGraph debugging

[Thomas Senyk]

Hi,

currently trying to debug a weird behavior on a TI chip (armv7 with a 
SGX GPU).


I have a fairly simple QML with a simple GridView with model:200 and 
delegate:Text{text: "T#"+index}.
(it's a tiny bit more then that, but for argument sake this should be 
enough)

Then an animation scrolling up and down (on "contentY", without items 
leaving the screen to avoid item creation in performance debugging).

So far so good .. plain 60fps, all frames ~16ms

But when I do
  color:  Qt.rgba(Math.random(), 1, 1,1);   [4]
on the Text-delegate, then I get very bad performance (<20fps).

Looking closer at the frame times it's good performance for a couple of 
frames (~16ms) and then one terrible frame with >200ms.

That in mind I dug further .. and found that it's:
In every "bad" frame
Updater::visitGeometryNode [1]
this is called with m_added==1

And this causes (because e->root==0 [2])
renderer->m_rebuild |= Renderer::FullRebuild;

Then nearly all the frame time (>200ms) is spend uploading the new 
batches in Renderer::uploadBatch [3]


Comparing all that with the "black"-case I see:
  - Batch  0 0x281f58 upload  root: 0x1a4a58
- element: 0x27ad18 Rect( -0.83 0.576389 27.4661 13.5365 ) 
node: GeometryNode( 0x27ab30 triangles #V: 12 #I: 18 x1= -0.83 y1= 
0.576389 x2= 27.4661 y2= 13.5365 materialtype= 0xb6fad3c4 )  order: 1
- element: 0x279ca0 Rect( 79.1667 0.732639 107.666 13.3889 )  node: 
GeometryNode( 0x279ab8 triangles #V: 12 #I: 18 x1= -0.83 y1= 
0.732639 x2= 27.6658 y2= 13.3889 materialtype= 0xb6fad3c4 )  order: 2
- element: 0x278c28 Rect( 159.167 0.576389 187.327 13.3889 )  node: 
GeometryNode( 0x278a40 triangles #V: 12 #I: 18 x1= -0.83 y1= 
0.576389 x2= 27.3273 y2= 13.3889 materialtype= 0xb6fad3c4 )  order: 3

...all in one Batch.

For color:
  - Batch  0 0x2845f8 upload  root: 0x16bd58
- element: 0x283a20 Rect( -0.83 0.576389 27.4661 13.5365 ) 
node: GeometryNode( 0x283838 triangles #V: 12 #I: 18 x1= -0.83 y1= 
0.576389 x2= 27.4661 y2= 13.5365 materialtype= 0xb6f583c4 )  order: 1
  - Batch  1 0x1702c8 upload  root: 0x16bd58
- element: 0x2829a8 Rect( 79.1667 0.732639 107.666 13.3889 )  node: 
GeometryNode( 0x2827c0 triangles #V: 12 #I: 18 x1= -0.83 y1= 
0.732639 x2= 27.6658 y2= 13.3889 materialtype= 0xb6f583c4 )  order: 2
  - Batch  2 0x2853a0 upload  root: 0x16bd58
- element: 0x281930 Rect( 159.167 0.576389 187.327 13.3889 )  node: 
GeometryNode( 0x281748 triangles #V: 12 #I: 18 x1= -0.83 y1= 
0.576389 x2= 27.3273 y2= 13.3889 materialtype= 0xb6f583c4 )  order: 3

... one node one batch [4].

So batching can't work on differently colored elements/text/..?
 ... is color a uniform per draw call?



 From the past I know that my test-case had good performance on older 
SoCs .. so the question I have right now are:

[1]: There shouldn't be a new Node .. nothing new is created?

[2]: Should one simple node cause all batches to be re-uploaded?
.. or better: why do I get Renderer::FullRebuild?

[3]: If all above is normal, then maybe it's the data upload that's to 
long? glBufferData in unmap is 300-400us on average (with ~200 of them 
in each "bad" frame) .. is that "normal"? sounds rather long for a 
couple of vertices (if it's only a couple of vertices?)

[4]: And again: I guess batching on non color-sharing elements is 
supposed to not work?



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

Re: [Development] QSceneGraph debugging

[Thomas Senyk]

On 11.06.2015 15:50, Gunnar Sletta wrote:
> Hi Thomas,
>
> You are hitting one of the less ideal code paths with this testcase, see my 
> comments below. I think the core problems are already outlined in 
> https://bugreports.qt.io/browse/QTBUG-42853.
>
>> On 11 Jun 2015, at 14:32, Thomas Senyk  wrote:
>>
>> Hi,
>>
>> currently trying to debug a weird behavior on a TI chip (armv7 with a
>> SGX GPU).
>>
>>
>> I have a fairly simple QML with a simple GridView with model:200 and
>> delegate:Text{text: "T#"+index}.
>> (it's a tiny bit more then that, but for argument sake this should be
>> enough)
>>
>> Then an animation scrolling up and down (on "contentY", without items
>> leaving the screen to avoid item creation in performance debugging).
>>
>> So far so good .. plain 60fps, all frames ~16ms
>>
>> But when I do
>>   color:  Qt.rgba(Math.random(), 1, 1,1);   [4]
>> on the Text-delegate, then I get very bad performance (<20fps).
>>
>> Looking closer at the frame times it's good performance for a couple of
>> frames (~16ms) and then one terrible frame with >200ms.
>>
>> That in mind I dug further .. and found that it's:
>> In every "bad" frame
>> Updater::visitGeometryNode [1]
>> this is called with m_added==1
>>
>> And this causes (because e->root==0 [2])
>> renderer->m_rebuild |= Renderer::FullRebuild;
>>
>> Then nearly all the frame time (>200ms) is spend uploading the new
>> batches in Renderer::uploadBatch [3]
>>
>>
>> Comparing all that with the "black"-case I see:
>>   - Batch  0 0x281f58 upload  root: 0x1a4a58
>> - element: 0x27ad18 Rect( -0.83 0.576389 27.4661 13.5365 )
>> node: GeometryNode( 0x27ab30 triangles #V: 12 #I: 18 x1= -0.83 y1=
>> 0.576389 x2= 27.4661 y2= 13.5365 materialtype= 0xb6fad3c4 )  order: 1
>> - element: 0x279ca0 Rect( 79.1667 0.732639 107.666 13.3889 )  node:
>> GeometryNode( 0x279ab8 triangles #V: 12 #I: 18 x1= -0.83 y1=
>> 0.732639 x2= 27.6658 y2= 13.3889 materialtype= 0xb6fad3c4 )  order: 2
>> - element: 0x278c28 Rect( 159.167 0.576389 187.327 13.3889 )  node:
>> GeometryNode( 0x278a40 triangles #V: 12 #I: 18 x1= -0.83 y1=
>> 0.576389 x2= 27.3273 y2= 13.3889 materialtype= 0xb6fad3c4 )  order: 3
>>
>> ...all in one Batch.
>>
>> For color:
>>   - Batch  0 0x2845f8 upload  root: 0x16bd58
>> - element: 0x283a20 Rect( -0.83 0.576389 27.4661 13.5365 )
>> node: GeometryNode( 0x283838 triangles #V: 12 #I: 18 x1= -0.83 y1=
>> 0.576389 x2= 27.4661 y2= 13.5365 materialtype= 0xb6f583c4 )  order: 1
>>   - Batch  1 0x1702c8 upload  root: 0x16bd58
>> - element: 0x2829a8 Rect( 79.1667 0.732639 107.666 13.3889 )  node:
>> GeometryNode( 0x2827c0 triangles #V: 12 #I: 18 x1= -0.83 y1=
>> 0.732639 x2= 27.6658 y2= 13.3889 materialtype= 0xb6f583c4 )  order: 2
>>   - Batch  2 0x2853a0 upload  root: 0x16bd58
>> - element: 0x281930 Rect( 159.167 0.576389 187.327 13.3889 )  node:
>> GeometryNode( 0x281748 triangles #V: 12 #I: 18 x1= -0.83 y1=
>> 0.576389 x2= 27.3273 y2= 13.3889 materialtype= 0xb6f583c4 )  order: 3
>>
>> ... one node one batch [4].
>>
>> So batching can't work on differently colored elements/text/..?
>>  ... is color a uniform per draw call?
>>
>>
>>
>>  From the past I know that my test-case had good performance on older
>> SoCs .. so the question I have right now are:
>>
>> [1]: There shouldn't be a new Node .. nothing new is created?
>
> I don’t understand the question.

Nothing in the UI is entering/leaving screen or explicitly 
created/destroyed ... so I wonder where the new Node comes from.

I'll look closer at what the Node is.

>
>>
>> [2]: Should one simple node cause all batches to be re-uploaded?
>> .. or better: why do I get Renderer::FullRebuild?
>
> It depends, but when you are adding and removing nodes it may happen. If this 
> is combined with plenty of batches this will kill performance. More than 100 
> discrete glMap/Unmap/Draw calls per frame is likely to not be feasible on 
> embedded hardware. And the renderer is also adding some overhead when the 
> number of batches go up.
>

Got it .. so somehow the above mentioned "new Node" causes all the 
restruct/data-re-upload .. we'll look into it.

>> [3]: If all above is normal, then maybe it's the data upload that's to
>> long? glBufferData in unmap is 300-400us on average (with ~200 of them
>> in each "

Re: [Development] QtWaylandCompositor public api

[Thomas Senyk]

On 31.08.2015 15:46, Lind Jorgen wrote:
> Hi all.
> 
> On Friday I pushed some patches to a branch called
> wip-compositor-api in the qtwayland repository. We want this branch
> to be the basis for a technology preview of the QtWaylandCompositor
> api. The branch has minimal fixes to the client side of the code,
> and mostly concentrates on restructuring and refactoring the Qt
> Compositor api. In the end the patches will all be squashed and
> pushed to the dev branch. The code will be put in a new
> subdirectory, leaving the old Qt Compositor code intact. The reason
> for this is to give people some headroom to change to the new api.
> In due time the old Qt Compositor code will be removed.
> 

I did a quick peak using git diff.
Seems like a lot of changes internally  .. and looking at
examples/qml-compositor the major difference at that:
You won't sub-class QWayland*Compositor anymore but instantiate it.
.. and therefor use signals rather then virtuals.

Any other major changes .. from a "simple c++ compositor"-perspective?

I did spot a couple of minor renaming (surfaceMapped vs.
mappedChanged), I'll look at them on a need to basis ;)


How stable/done is this? Is it worth while trying to port an existing
compositor to the new API?
If it's stable enough to count an effort like that between "API
review" and "actual forward port" then I'd give it a try in 2-3 weeks
(unless something comes up -- as always).


What's assumed ETA for moving wip-compositor-api to default API? 5.6? 5.7?


Greets
Thomas





> Br, Jørgen
> 
> 
> ___ Development mailing
> list Development@qt-project.org 
> http://lists.qt-project.org/mailman/listinfo/development
> 

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

[Development] leak in QMetaObject?

[Thomas Senyk]

Hi,

I lately wanted to validate that a connecting&disconnecting to a lambda
will not leak the lambda object .. and found that more then that is leaked.

Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv

After the 10million connections are executed and disconnected (all of
them a successful), I assume a drop in memory consumption and more
importantly a drop of cpu load to close to 0%.

I see neither one nor the other. I see continues 100% consume with no
memory consumption drop what so ever.

I did a quick peak into QMetaObject::activate and it seems no clean up
happened .. the list returned in
  list = &connectionLists->at(signal_index);
  (line #3660 in 5.6 checkout from today)

seems rather long! (10million?)

However all "if (!c->receiver)" shows no receiver and therefor will
continue right away .. at least

Is this expected? A bug? ... I'm happy to fill a bug report, I just
wanted to get some feedback, maybe I'm just doing something wrong



Some background:
I wanted to check if a single-shot-connection (connection to a signal
and disconnect at first execute, using a lambda as slot) would be a
feasible thing to do.

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

Re: [Development] leak in QMetaObject?

[Thomas Senyk]

On 14.07.2016 17:18, André Somers wrote:
> 
> 
> Op 14/07/2016 om 17:10 schreef Olivier Goffart:
>> On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
>>> Hi,
>>>
>>> I lately wanted to validate that a connecting&disconnecting to a lambda
>>> will not leak the lambda object .. and found that more then that is
>>> leaked.
>>>
>>> Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
>>>
>>> After the 10million connections are executed and disconnected (all of
>>> them a successful), I assume a drop in memory consumption and more
>>> importantly a drop of cpu load to close to 0%.
>>>
>>> I see neither one nor the other. I see continues 100% consume with no
>>> memory consumption drop what so ever.
>>>
>>> I did a quick peak into QMetaObject::activate and it seems no clean up
>>> happened .. the list returned in
>>>list = &connectionLists->at(signal_index);
>>>(line #3660 in 5.6 checkout from today)
>>>
>>> seems rather long! (10million?)
>>>
>>> However all "if (!c->receiver)" shows no receiver and therefor will
>>> continue right away .. at least
>>>
>>> Is this expected? A bug? ... I'm happy to fill a bug report, I just
>>> wanted to get some feedback, maybe I'm just doing something wrong
>>
>> The lambda object and its capture is destroyed by the call to
>>slotObj->destroyIfLastRef()
>>
>> The internal data structre (QObjectPrivate::Connection) is deleted by
>> QObjectPrivate::cleanConnectionLists which is actually only called when
>> a new connection is made to this object.
>>
>> I don't think there is a leak, but it is true that some memory is only
>> free'ed
>> when you add new connection or that the object is destroyed. (but the
>> lambda
>> object is destroyed right after the disconnection)

Then this:
http://paste.ofcode.org/37rxyitynhEqi5gira88hR9

should "fix" it? .. but I still see 100% cpu and same memory consumption?


>>
>>
>>> Some background:
>>> I wanted to check if a single-shot-connection (connection to a signal
>>> and disconnect at first execute, using a lambda as slot) would be a
>>> feasible thing to do.
>> You can do that already:
>>
>>   QTimer::sigleShot(100, [] { qDebug() << "hello"; });
>>
> That's not the same thing.
> This looks like my earlier suggestion
> https://bugreports.qt.io/browse/QTBUG-44219

+1, this is similar but not the same,

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

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

Re: [Development] leak in QMetaObject?

[Thomas Senyk]

On 14.07.2016 16:48, Giuseppe D'Angelo wrote:
> On Thu, Jul 14, 2016 at 4:33 PM, Thomas Senyk
>  wrote:
>>
>> Is this expected? A bug? ... I'm happy to fill a bug report, I just
>> wanted to get some feedback, maybe I'm just doing something wrong
> 
> First and foremost, which Qt version are you using? :)
> 

Ah yes .. I only mentioned it in the sub-text :)
5.6 branch from git (checkout from this morning)


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

Re: [Development] leak in QMetaObject?

[Thomas Senyk]

On 14.07.2016 18:25, Thiago Macieira wrote:
> On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote:
>> should "fix" it? .. but I still see 100% cpu and same memory consumption?
> 
> Can you attach the debugger to see what it is still doing after you're done?
> 

Still the same, goes in circles around in QMetaObject::activate

#3671 => #3673 =>  if (!c->receiver) continue => while => ...
... pressing F10 for a while doesn't let you out of that (short) cycle.

If you want to know (I know it's not saying much) the values for
list->first and list->last: @0x1529ac0, @0x6a3a3250


Is that what you wanted to know? If I misunderstood, please clarify :)

Greets
Thomas

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

Re: [Development] leak in QMetaObject?

[Thomas Senyk]

On 14.07.2016 18:56, Thiago Macieira wrote:
> On quinta-feira, 14 de julho de 2016 18:37:17 PDT Thomas Senyk wrote:
>> On 14.07.2016 18:25, Thiago Macieira wrote:
>>> On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote:
>>>> should "fix" it? .. but I still see 100% cpu and same memory consumption?
>>>
>>> Can you attach the debugger to see what it is still doing after you're
>>> done?
>> Still the same, goes in circles around in QMetaObject::activate
>>
>> #3671 => #3673 =>  if (!c->receiver) continue => while => ...
>> ... pressing F10 for a while doesn't let you out of that (short) cycle.
>>
>> If you want to know (I know it's not saying much) the values for
>> list->first and list->last: @0x1529ac0, @0x6a3a3250
>>
>>
>> Is that what you wanted to know? If I misunderstood, please clarify :)
> 
> I wanted a backtrace. Are you saying the trace is 3700 frames deep?
> 

Sorry that was line numbers :) No it's not.

http://paste.ofcode.org/u3gGqxAfX9hWefeUszDEx

About to generate a callgrind output.

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

[Development] QServiceClientCredentials

[Thomas Senyk]

What's up with the remote-service-cedentials?
It seams to be only part of the documentation, but no class, struct or 
anything else in Qt5 QtLocation

It's still part of the documentation:
http://doc.qt.nokia.com/qt5/service-frameworks.html#service-security


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

Re: [Development] QServiceClientCredentials

[Thomas Senyk]

On Monday, March 12, 2012 02:53:32 PM Blasche Alex wrote:
> Hi Thomas,
> 
> > -Original Message-
> > From: development-bounces+alex.blasche=nokia@qt-project.org
> > [mailto:development-bounces+alex.blasche=nokia@qt-project.org] On
> > 
> > What's up with the remote-service-cedentials?
> > It seams to be only part of the documentation, but no class, struct or
> > anything else in Qt5 QtLocation
> 
> The class is part of the Qt ServiceFramework module
> (qtsystems/src/serviceframework) and not the Qt Location module.

right, just a "typo" @ location 

And after doing the right grep I found it :) It's still called 
QRemoteServiceRegisterCredentials

... as it's called in the QtMobility code and doc, but it's call
QServiceClientCredentials
in the Qt5 doc.

Any reason for the mismatch?


> 
> --
> Alex
> 
> > It's still part of the documentation:
> > http://doc.qt.nokia.com/qt5/service-frameworks.html#service-security
> > 
> > 
> > Greets
> > Thomas
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Missing "QML Doc"

[Thomas Senyk]

Hi,

does anyone know why: 
http://doc-snapshot.qt-project.org/5.0/qtquick2-qdeclarativeelements.html

is missing  (that's the link when you click on "QML Elements")


by the way: http://doc.qt.nokia.com/qt5/qtquick2-qdeclarativeelements.html
exists.

Greets
Thomas

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

Re: [Development] Not stripping our binaries by default

[Thomas Senyk]

On Fri, September 14, 2012 04:08:57 PM Thiago Macieira wrote:
> On sexta-feira, 14 de setembro de 2012 14.56.08, Oswald Buddenhagen wrote:
> > > If it is, I'll instead add an option to configure that toggles the
> > > "nostrip"  option in CONFIG.
> > 
> > that would be preferable.
> 
> Commit updated.
> 
> I made it default to no-stripping.

Why? Shouldn't stripping be the default?
Having "some" information in the binary isn't very helpful anyway.
I agree that package manager need something to disable stripping if it needs 
to happen in another stage of package build, but that's no argument for having 
it off on default.

A argument for stripping as default:
A lot of people don't know what's the right thing to do in most cases ... so 
the "best" option should be taken. and the best options are IMHO:
- debug build -> all information
- release build -> best possible performance/size/...

> 
> The option does not apply to Windows's configure.exe because you're not
> supposed to make install there.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Not stripping our binaries by default

[Thomas Senyk]

On Fri, September 14, 2012 04:35:47 PM Thiago Macieira wrote:
> On sexta-feira, 14 de setembro de 2012 16.21.44, Thomas Senyk wrote:
> > On Fri, September 14, 2012 04:08:57 PM Thiago Macieira wrote:
> > > I made it default to no-stripping.
> > 
> > Why? Shouldn't stripping be the default?
> 
> I don't think it should, neither does Simon. But Lars, Ossi and you think it
> should.
> 
> Since I prepared the patch while there's no consensus, I opted to go for my
> preference.

Hmm I mainly agree with most of your arguments.
The use-case I have in mind is cross-compiling, where people not always know 
what they are doing ;)

One thing which could reduce that problem is adding it stripping-setting to 
the configure-output? 

> 
> > Having "some" information in the binary isn't very helpful anyway.
> > I agree that package manager need something to disable stripping if it
> > needs to happen in another stage of package build, but that's no argument
> > for having it off on default.
> > 
> > A argument for stripping as default:
> > A lot of people don't know what's the right thing to do in most cases ...
> > so the "best" option should be taken. and the best options are IMHO:
> > - debug build -> all information
> > - release build -> best possible performance/size/...
> 
> We're using -O2 in release mode, which increases code size. If size was an
> issue, we'd have -Os.
> 
> What's more, EVERYTHING out there except for Qt builds with no stripping by
> default. I think being consistent is more important.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 Beta cross compiling problem

[Thomas Senyk]

On Thu, September 27, 2012 05:11:23 PM Christoph Kurz wrote:
> Hi,
> 
> I have a problem cross compiling the Qt5-Beta for an i.MX6 Board.
> The host OS is a Fedora Linux, the target OS is an embedded Linux.
> 
> Steps taken so far:
> 
> – I set up LTIB and created a rootfs for the target.
> 
> – I downloaded the Qt5 sourcecode and excluded svg and webkit by renaming
> the corresponding folders
> 
> – I copied the linux-imx6-makespec in the qtbase/mkspecs folder (see
> attachment "config.txt")

Their is a naming convention for mkspecs ... not sure how it's definition looks 
exactly, but it should be named: linux-imx6-g++

Anyway, you could have saved your self a lot of work by using the 
device-mkspec: mkspecs/devices/linux-imx6-g++

(Their is also a patch to simplify it: 
https://codereview.qt-project.org/#change,31908  
... but the one in master should do it as well )

This is made with/for ltib, so it should work ... if not: let me know!

> 
> - I configured the build with the following command (runs without any
> errors): ./configure -prefix /home/local/CW01/uidv7014/Qt_for_target
> -developer-build -confirm-license -opensource -nomake tests -nomake docs
> -nomake demos -nomake examples -no-xcb -no-wayland -xplatform linux-imx6
> -arch armv7 -opengl es2 -openvg -eglfs -release -v

-openvg is useless at the moment :) No openvg code in qt5

> 
> - I tried to run make, but after a while, an error occurs (see attachment
> "error.txt")
> 
> 
> 
> As this error seems to occur in the neon-package, I excluded it by using the
> -no-neon option in the configure-command. This seems to work, but then a
> very similar error occurs in the sqlite-package and in various other
> packages, too.

Not sure about that error .. have never seen it 
   (It could(!) be caused by violating the mkspec-naming-schema, but not very 
likely)

What you can try is:
 - find out where and how those missing symbols are defined 
(should be a simple grep)
 - find out why he isn't building and/or linking those symbols 
(maybe a .o-file is missing, or a define is set wrong/is not set...)

I would guess it's a bug in some project file regarding neon ... or a multi-
layer-#ifdef-bug in a .cpp file

Can you post the sqlite-package error? ... Maybe they are totally unrelated 
and just not trigger he can't link gui

> 
> I compiled the Qt5 Alpha successfully, using the same specs and environment.
> 
> Any ideas?
> 
> 
> 
> - Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 Beta cross compiling problem

[Thomas Senyk]

On Thu, September 27, 2012 07:19:50 PM Thiago Macieira wrote:
> On quinta-feira, 27 de setembro de 2012 18.37.18, Thomas Senyk wrote:
> > Their is a naming convention for mkspecs ... not sure how it's definition
> > looks exactly, but it should be named: linux-imx6-g++
> 
> No, it shouldn't. It should be linux-g++-imx6. There are several sections of
> the .pro files that test for "--*", e.g. in simd.prf:
> 
> *-g++*|linux-icc*|*-clang*|*-qcc* {

A good to know! Thanks.

But this is not followed strictly :)

Most of the wince mkspecs have there architecture between  and 
(where all other have it at the end (e.g. linux-g++-64)

And similar to that, all(!) device spec's are like:
linux-[arch-]-g++


> 
> But you have nailed the problem for this particular case: simd.prf checks
> for *-g++* (that's it above), which his mkspec naming doesn't match.
> 
> > Not sure about that error .. have never seen it
> > 
> >(It could(!) be caused by violating the mkspec-naming-schema, but not
> > 
> > very likely)
> 
> It actually is :-/

hehe ok, my guessing skill is better then I though :D
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 Beta cross compiling problem

[Thomas Senyk]

One side note, as I just stumbled over it:
I need to pass: -no-pch to configure

See: http://qt-project.org/forums/viewthread/20202

On Thu, September 27, 2012 05:11:23 PM Christoph Kurz wrote:
> Hi,
> 
> I have a problem cross compiling the Qt5-Beta for an i.MX6 Board.
> The host OS is a Fedora Linux, the target OS is an embedded Linux.
> 
> Steps taken so far:
> 
> – I set up LTIB and created a rootfs for the target.
> 
> – I downloaded the Qt5 sourcecode and excluded svg and webkit by renaming
> the corresponding folders
> 
> – I copied the linux-imx6-makespec in the qtbase/mkspecs folder (see
> attachment "config.txt")
> 
> - I configured the build with the following command (runs without any
> errors): ./configure -prefix /home/local/CW01/uidv7014/Qt_for_target
> -developer-build -confirm-license -opensource -nomake tests -nomake docs
> -nomake demos -nomake examples -no-xcb -no-wayland -xplatform linux-imx6
> -arch armv7 -opengl es2 -openvg -eglfs -release -v
> 
> - I tried to run make, but after a while, an error occurs (see attachment
> "error.txt")
> 
> 
> 
> As this error seems to occur in the neon-package, I excluded it by using the
> -no-neon option in the configure-command. This seems to work, but then a
> very similar error occurs in the sqlite-package and in various other
> packages, too.
> 
> I compiled the Qt5 Alpha successfully, using the same specs and environment.
> 
> Any ideas?
> 
> 
> 
> - Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 Beta cross compiling problem

[Thomas Senyk]

On Fri, September 28, 2012 01:30:34 PM Thiago Macieira wrote:
> On sexta-feira, 28 de setembro de 2012 11.16.42, Thomas Senyk wrote:
> > > No, it shouldn't. It should be linux-g++-imx6. There are several
> > > sections
> > > of the .pro files that test for "--*", e.g. in simd.prf:
> > > 
> > > *-g++*|linux-icc*|*-clang*|*-qcc* {
> > 
> > A good to know! Thanks.
> > 
> > But this is not followed strictly :)
> 
> I can't find any "linux-g++*" in our source code, which is the most likely
> one to cause problems (cross-compilation to embedded devices). That means
> you've just got away with it, for the time being. It might break at any
> time.
> > Most of the wince mkspecs have there architecture between  and
> >  (where all other have it at the end (e.g. linux-g++-64
> > 
> > And similar to that, all(!) device spec's are like:
> > linux-[arch-]-g++
> 
> Those are new things and, clearly, all wrong.
> 
> It's linux-g++-. I reserve the right to unintentionally break
> any mkspec not following that rule. Therefore, please rename them all at
> the earliest opportunity.
> 
> That said, one of Ossi's recent changes was to have the compiler name in a
> different variable, so we avoid this problem completely. Depending on the
> mkspec was fragile.

I'm not sure I get what you trying to tell me :)

Is it "You should change now, but if you're lucky you could get away with 
beeing "lazy" and wait until ossi's changed settled and change then 
accordingly"?

... because if so, I would rather wait, because right now it's working and if 
we need to change it soon anyway I would rather do one change then two.


(by the way: the change is more then just renaming folders)

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

Re: [Development] Antialiasing

[Thomas Senyk]

On Fri, October 05, 2012 02:51:09 PM Samuel Rødal wrote:
> On 10/05/2012 02:28 PM, Wehmer, Matthias wrote:
> > Hi Samuel,
> > 
> > I will try to make myself clearer, sorry for that unclear information.
> > 
> > The shaders I’m talking about are those, that I implemented in my custom
> > Qml plugin via the QSGSimpleMaterial class. There I have implemented two
> > custom versions of the vertex and the fragment shader, whereby the later
> > is just coloring the scene. OpenGL itself is involved in such a way as I
> > use it to pass a texture to the fragment shader, but the geometry for
> > example is created with the methods and objects given by Qt, i.e. I use
> > a QSGGeometryNode and attach my geometry to it and simply draw a
> > Line_Strip between them.
> > 
> > The setAntialiasing() method I talk about is the one from the QQuickItem
> > class.
> 
> Yep, this was implemented recently and is a way to get antialiasing
> without using multisample buffers (since those consume a lot of memory).
> It does antialiasing in the fragment shader, by adding a set of
> triangles around the shape (in the case of a Rectangle), and doing a
> fade-out of the material around the edges. I believe it needs to be
> implemented by each item / node somehow.

Hui! That's nice ... not a solution for the old FBO-AA-problem, but anyway: 
nice! :)


> 
> >  From my understanding this method should turn on some kind of
> > 
> > postprocessing, that is antialise the scene after it is drawn by the
> > SceneGraph. Obviously this doesn’t work for my custom widget, although
> > all other items are antialiased. So either I understand this option and
> > its consequences wrong or I need to implement some postprocessing on my
> > own. For that I would need access to the scene (in form of a texture)
> > after it has been drawn by the SceneGraph. Is there a possibility for
> > that? Do you see my problem and what I understand wrong? I’m kinda
> > struggling right now, because the whole rendering mechanism seems to be
> > a black box for me. :D
> 
> It is not a postprocessing feature. I'd suggest to have a look at how
> the Rectangle element implements the antialiasing.
> 
> Of course, you can also use multisampling by doing setSamples(4) or
> similar on the QQuickView's surface format.
> 
> --
> Samuel
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwayland module fails to build for Raspberry Pi

[Thomas Senyk]

On Tue, October 16, 2012 02:36:33 PM Thiago Macieira wrote:
> On terça-feira, 16 de outubro de 2012 15.25.40, Jon Trulson wrote:
> > However, compiling qtwayland fails with many errors - errors that
> > imply qtwayland cannot work with the wayland installed on the rpi.
> 
> Probably. Upgrade your Wayland to 0.95 at least.
> 
> I haven't done any testing with 0.99 yet to see if it works. I'll get to it
> later this week.

I've tested with 0.99 yesterday ... 
I had multiple API-incompatible-errors:

error: 'wl_display_bind' was not declared in this scope
error: ‘wl_display_add_global_listener’ was not declared in this scope
error: too many arguments to function ‘int wl_display_get_fd(wl_display*)
...


Therefor I switched back to wayland-git and the sha1 in wayland_sha1.txt

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

Re: [Development] qtwayland module fails to build for Raspberry Pi

[Thomas Senyk]

On Fri, October 19, 2012 09:14:39 AM Chris Adams wrote:
> On Fri, Oct 19, 2012 at 2:06 AM, Jon Trulson  wrote:
> > On Tue, 16 Oct 2012, Thiago Macieira wrote:
> >  On terça-feira, 16 de outubro de 2012 15.25.40, Jon Trulson wrote:
> >>> However, compiling qtwayland fails with many errors - errors that
> >>> imply qtwayland cannot work with the wayland installed on the rpi.
> >> 
> >> Probably. Upgrade your Wayland to 0.95 at least.
> > 
> > Ok, I tried this - got wayland itself to build, but qtwayland fails
> > compiling compositor_api/**waylandsurfaceitem.cpp:
> > 
> > compositor_api/**waylandsurfaceitem.cpp:55:32: fatal error:
> > QtQuick/QQuickCanvas: No such file or directory
> > 
> > I believe this header was depricated some time ago?
> 
> It was renamed to QQuickWindow.

and it's already fixed ... so a git pull in qtwayland should help

> 
> > I will try the SHA1 mentioned in emails below - but IIRC when I tried
> > that originally, it too failed due to changes made in
> > waylandresourcecollection.cpp and waylandresourcecollection.h in later
> > qtwayland commits.
> > 
> > I will try this again right now though - maybe I missed something, it
> > was a long night :)
> > 
> > 
> > 
> > --
> > Jon Trulson
> > 
> > The Higgs Field is what make atoms matter.
> > 
> > -- Tom L.
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QT.module.rpath is not used properly

[Thomas Senyk]

Hi Folks,

I got a self-written mkspec for the rasp-pi and everything is working as 
expected.

With one exception, for external applications he is not adding the proper
 -Wl,-rpath,


The problem is that:
cat /usr/local/Trolltech/Qt5-rasp-pi-2/mkspecs/modules/qt_lib_* |grep rpath

returns nothing.

 --> the installed module pri files do not contain the rpath and rpath-link 
variables anymore.

The ones in the qt-build-directory do.
e.g.: qt_lib_core.pri contains:
QT.core.rpath = /usr/local/Trolltech/Qt5-rasp-pi-2/lib



Any though how/why they vanished?



FYI:
If you add a module to "QT" in your project file, qt_functions.prf:93 will add:
 -Wl,-rpath,/

...which is totally wrong... but maybe expected if QT.module.rpath is empty?

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

Re: [Development] Qt5 Beta/Qt Quick 2.0 and Antialiasing

[Thomas Senyk]

On Tue, October 30, 2012 11:14:46 AM Labs, Torsten wrote:
> Hello,
> 
> we created some prototype with Qt Quick 2 on a ARM board. Its running verry
> well except antialiasing. As i can see in the Qt5 Documentation there is a
> new flag for antialiasing *  
> antialiasing iasing-prop> : bool
> 
> but this makes no difference. Is there still a bug?
> 
> Thx
> 
> Torsten

In general it's the duty of the platform plugin (I assume eglfs or 
minimalegl?) to provide a native-surface which has multisampling.


The application-level API to request a multisample surface is:
http://doc-snapshot.qt-project.org/5.0/qsurfaceformat.html#setSamples

Then set the changed surfaceformat with:
http://doc-snapshot.qt-project.org/5.0/qwindow.html#setFormat


If it's still not working, you need to check what's going in the platform-
plugin
 - Is their a native egl/opengl-surface which has multisampling aviable?
 - Is the platform-plugin using it? why not?


Greets
Thomas

> 
> 
> 
> With best regards,
> Torsten Labs
> 
> Siemens AG
> Industry Sector
> Industry Automation Division
> Industrial Automation Systems
> Factory Automation
> I IA AS FA WF FTH 2
> Siemensstr. 2-4
> 90766 Fuerth, Germany
> Tel.: +49 911 978-3682
> mailto:torsten.l...@siemens.com
> 
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard
> Cromme; Managing Board: Peter Loescher, Chairman, President and Chief
> Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe
> Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y.
> Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany;
> Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684;
> WEEE-Reg.-No. DE 23691322
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QT.module.rpath is not used properly

[Thomas Senyk]

On Tue, November 06, 2012 08:21:24 PM Oswald Buddenhagen wrote:
> On Tue, Nov 06, 2012 at 06:17:04PM +0100, Thomas Senyk wrote:
> > I got a self-written mkspec for the rasp-pi and everything is working as
> > expected.
> > 
> > With one exception, for external applications he is not adding the proper
> > 
> >  -Wl,-rpath,
> > 
> > The problem is that:
> >   cat /usr/local/Trolltech/Qt5-rasp-pi-2/mkspecs/modules/qt_lib_* |grep
> >   rpath
> > 
> > returns nothing.
> 
> that's not the problem.
> 
> > If you add a module to "QT" in your project file, qt_functions.prf:93 will 
add:
> >  -Wl,-rpath,/
> 
> *that* is the problem.
> the fallback path doesn't account for sysroots. and it cannot do that
> cleanly. so it should be scrapped.

but isn't that what the patch tried to do by using $$[QT_INSTALL_LIBS/raw] ?
QT_.../raw variables are variables "without SYSROOT-prefix", right?

I've no real clue about what qt_module.prf does and how it works ... but if 
it's the one taking care about preparing the installed versions of module-pri-
files then the second part of the patch looks like dealing with the root 
problem. (the fact that QT.module.rpath) is missing.

IMO the problem is not the fallback in qt_function.prf, it's the fact that the 
fallback is trigger.



... but hey, I'm clearly no expert on the whole module-mkspecs-architecture .. 
what ever you decide is good with me as long as I get a proper -rpath in the 
end ;)

Greest
Thomas

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

Re: [Development] Qt5 Beta/Qt Quick 2.0 and Antialiasing

[Thomas Senyk]

On Wed, November 07, 2012 09:34:49 AM Sean Harmer wrote:
> On Tuesday 06 November 2012 18:47:43 Thomas Senyk wrote:
> > On Tue, October 30, 2012 11:14:46 AM Labs, Torsten wrote:
> > > Hello,
> > > 
> > > we created some prototype with Qt Quick 2 on a ARM board. Its running
> > > verry
> > > well except antialiasing. As i can see in the Qt5 Documentation there is
> > > a
> > > new flag for antialiasing *
> > > antialiasing<http://qt-project.org/doc/qt-5.0/qml-qtquick2-item.html#ant
> > > ia
> > > l
> > > iasing-prop> : bool
> > > 
> > > but this makes no difference. Is there still a bug?
> > > 
> > > Thx
> > > 
> > > Torsten
> > 
> > In general it's the duty of the platform plugin (I assume eglfs or
> > minimalegl?) to provide a native-surface which has multisampling.
> > 
> > 
> > The application-level API to request a multisample surface is:
> > http://doc-snapshot.qt-project.org/5.0/qsurfaceformat.html#setSamples
> > 
> > Then set the changed surfaceformat with:
> > http://doc-snapshot.qt-project.org/5.0/qwindow.html#setFormat
> > 
> > 
> > If it's still not working, you need to check what's going in the platform-
> > plugin
> > 
> >  - Is their a native egl/opengl-surface which has multisampling aviable?
> >  - Is the platform-plugin using it? why not?
> 
> I think the default was changed to request a surface without multisampling
> and instead Rectangle, Image etc were changed to implement their own
> anti-aliasing by means of a trick in the vertex shader.
> 
> You should still be able to explicitly request multisampling by setting the
> surface format explicitly though.

Yes!

 ... my last two sentences were about the platform-plugin.
Sometimes they need some tweaking to get it right.
(e.g. tegra2 has it's own mutlisampling-extension and one needs to pass 
special values to eglChooseConfig to get a multisampled-surfaces)

That's what I meant with "is their a one" and "is the platform-plugin using 
it"


> 
> Sean
> 
> --
> Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] about directfbegl platform

[Thomas Senyk]

On Mon, November 05, 2012 12:10:05 PM thouraya andolsi wrote:
> Hi,
> 
> 
> I compiled Qt-5.0.0-beta1 release for armv7/directfb  platform.
> After compiling and installing sucessfully, I tried to run MiniBrowser, but
> I has got the following error:
> 
> ./MiniBrowser -platform directfbegl http://www.google.com
> 
> Failed to load platform plugin "xcb". Available platforms are:
> directfbegl
> directfb
> linuxfb
> minimal
> 
> 
> Why it is trying to load the "xcb plugin for directfbegl platform ?

That's weird ;)
Have you either used '-qpa xcb' during configure or have you set
QT_QPA_DEFAULT_PLATFORM during configure/compile-time?
(If you're using a foreign mkspec, please check it carefully!)

That's the only reason I can see why he would try to load a non-existing 
plugin... but maybe someone from the QPA team can comment

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

Re: [Development] Qt3D Maintainer

[Thomas Senyk]

On Fri, November 16, 2012 04:03:12 PM Sean Harmer wrote:
> Hi everybody,
> 
> I hope everyone who attended the Qt Developer Days has recovered now.
> One topic that came up a few times in discussions there was the
> maintainership of the Qt3D module. This module has seen very few commits
> recently and as already noted on the list will not form part of the
> official Qt5 release.
> 
> To breathe some life back into this module myself and, James Turner
> , are hereby offering to take over the development and
> maintainership of Qt3D.
> 
> I have only made a few commits to this module in the past as I have been
> concentrating on other parts of the OpenGL stack elsewhere to be ready
> for Qt5. However, as those of you who attended the OpenGL training
> and/or talks will know, OpenGL with Qt is something that I care deeply
> about and would like to see as part of a future Qt5.x release. I have
> some ideas on some neat things we could add to Qt3D in the future but it
> will take a little while to review the current status of the code and
> get to grips with it.

I can imagine  ... I personally never dared to look too deep ;)
> 
> I would like to ask for some feedback from the list as to whether this
> would be an acceptable way forwards for this module.
> 
> Kind regards,
> 
> Sean

Nice! great that you're brave enough to step up :)

Be prepared to receive bug reports and features requests ;) 
 ... hopefully some changes to review as well :)


If I can help be testing, reviewing or anything else, let me know.


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

Re: [Development] QRE: QML Tooling Renames (was: Pending decisions on co-installation)

[Thomas Senyk]

On Wed, November 21, 2012 07:59:54 AM Koehne Kai wrote:
> > -Original Message-
> > From: development-bounces+kai.koehne=digia@qt-project.org
> > [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
> > Behalf Of Samuel Rødal
> > Sent: Wednesday, November 21, 2012 8:34 AM
> > To: development@qt-project.org
> > Subject: Re: [Development] QML Tooling Renames (was: Pending decisions
> > on co-installation)
> > 
> > On 11/20/2012 05:05 PM, Alan Alpert wrote:
> > > On Tue, Nov 20, 2012 at 8:00 AM, Jana Aurindam
> > 
> >  wrote:
> >  To summarize QML tool naming discussion so far:
> >  
> >  In qtquick1 repo
> >  qmlviewer -> qml1viewer
> >  qmlplugindump  -> qml1plugindump
> > >>> 
> > >>> That's already the name, isn't it?
> > >>> 
> >  In qtdeclarative repo
> >  qmlscene -> qml2scene
> >  qmlplugindump  -> qml2plugindump
> >  qmlbundle -> move to playground
> >  qmlmin -> qmlmin
> >  qmlprofiler -> qmlprofiler
> >  qmltestrunner -> qml2testrunner
> >  qmleasing -> qml2easing
> >  easingcurveeditor -> qml2easing (merge tools)
> >  
> >  Does anyone have any further feedback on QML tool renaming before
> >  these get implemented?
> > >>> 
> > >>> I don't feel too strong about the particular names anymore. But if
> > >>> you're
> > 
> > changing the names of especially qmlplugindump, qmlviewer, qmlscene, it
> > should go in fast ! We need to fix Qt Creator then, too, and I >guess also
> > a bunch of documentation ...
> > 
> > >> I am quite against the renaming of binaries.
> > >> Does qml2scene mean that there is an equivalent qml1scene?
> > >> what is the difference between qmlviewer in qt 4.8 and qt 5.0 that a
> > 
> > renaming is necessary?
> > 
> > > Differences between qmlviewer and qmlscene qmlviewer only:
> > > -Renders QtQuick 1 scenes.
> > > -Has some built in testing functionality -Has some additional
> > > development UI (logger window, screen shots, and such) qmlscene only:
> > > -Renders QtQuick 2 scenes.
> 
> The difference in the feature set is something that just happened, and I
> could imagine that qmlscene gets some features back over time. The key to
> me is that people are using the tool for the exact same purpose :
> pre-viewing  QML files. That's why I originally proposed qml1viewer,
> qml2viewer.
> > > If the names are left as they are, it's not entirely clear which to
> > > use in your development. qml1viewer for qml1 and qml2scene for qml2
> > > makes this fairly clear.
> > 
> > One core difference is that qmlviewer uses QDeclarativeView and qmlscene
> > uses the scene graph.
> 
> Well, actually qmlviewer uses a QDeclarativeView that's based on
> QGraphicsView framework, and qmlscene uses a QQuickView that's based on
> scene graph (QSG*) :) So it's a bit more convoluted, and I don't think most
> users will intuitively grasp the connection , let alone really understand
> the relations between QML, Declarative, qtdeclarative & qtquick1 folders,
> QtQuick 1, Qt Quick 2, [QtQuick]SceneGraph, QGraphicsView ... In Qt Creator
> at least we're moving more and more towards using 'Qt Quick 1' and 'Qt
> Quick 2' to differentiate between both stacks. So there's e.g. a 'Qt Quick
> 1 Application Template', and a 'Qt Quick 2 Application Template'. If
> qtquick1previewer wouldn't be such an awful name it would have my vote ;)

+1
IMO this is the technical correct term! 
(at least until "qtquick1", the rest is debatable)

The language (qml) is not changing between QtQuick1 and QtQuick2


The alternative is to define the name by engine/runtime used, this would result 
in: 
 - qmlview[er] (as in QDeclarativeVIEW)
 - qmlscene  (as in QQuickSCENE)

;)


> 
> Anyway, it's just names, and it seems most people don't mind to much,
> whatever it's called.
> > I presume that if we did a QtQuick 3.0 it might still
> > use the scene graph, and thus we'd still use qmlscene to run QtQuick 3.0
> > applications. Or do we want to end up with qml3scene, qml4scene, etc?
> > 
> > Or, is the versioning of QML, the language, completely decoupled from the
> > versioning of QtQuick, the set of basic components and enablers for UI
> > development? If so I guess it makes sense that qml2scene could still run
> > QtQuick 3.0 applications if that would still use version 2 of QML.
> > We're not very explicit about the language versioning in code nor in
> > documentation though.
> 
> I think it's futile to speculate how QtQuick 3.0 will look like. Will it be
> just a new namespace / items, a new library, a new QML language, a complete
> new stack? Will it be part of Qt 5.x or not? I think nobody knows, and if
> the worst case happens I think adapting tool names during Qt 5.x lifetime
> is an option.
> 
> Regards
> 
> Kai
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Developme

Re: [Development] Request: QML Presentation System on qt-project.org

[Thomas Senyk]

On Mon, November 26, 2012 12:29:24 Sletta Gunnar wrote:
> Hi,
> 
> I've gotten a few requests to include the QML Presentation System into the
> Qt Project. It would simplify code reviews and future contributions. What
> do you think?
> 
> Current location: https://qt.gitorious.org/qt-labs/qml-presentation-system.
> 
> As new location I would suggest qt-labs/qml-presentation-system and myself
> as maintainer.

+1

I maintain a few things in my own repos on gitorious, some of those changes 
could be up-streamed

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

Re: [Development] Comparing two reals in Qt code

[Thomas Senyk]

On Thu, November 29, 2012 14:53:21 Sean Harmer wrote:
> On Thursday 29 November 2012 15:01:05 Dominik Holland wrote:
> > Hi all,
> > 
> > last month i had some performance problems on a QML animation running on
> > low end hardware (imx233).
> > I debugged that problem and it was caused because of rounding errors
> > during the comparison of two reals.
> > 
> > I fixed that problem by replacing the comparison by a qFuzzyCompare() in
> > the Qt4 declarative source code.
> > Afterwards i checked whether qt5 has the same problem... and it has
> > exactly the same problem.
> > 
> > Now i pushed my patch to gerrit
> > (https://codereview.qt-project.org/#change,40655) and looked again at
> > the code
> > for any other occurrences.
> > 
> > What i found is, that this happens in many places and it would be a
> > really huge effort to change the code to compare the qreals in the right
> > way.
> > 
> > Is this already a known problem and do you think that it is worth to try
> > to fix the code ?
> 
> Also please be aware that qFuzzyCompare() is nto the right way to compare
> two arbitrary floating point values. If one of them is zero or close to
> zero the condition it tests for becomes impossible to satisfy.
> 
> Something along the lines of
> 
> fuzzyCompare(float p1, float p2)
> {
> if (qFuzzyIsNull(p1))
> return qFuzzyIsNull(p2);
> else if (qFuzzyIsNull(p2))
> return false;
> else
> return qFuzzyCompare(p1, p2);
> }
> 
> is slightly better but still not fantastic. Comparing two floats that we do
> not know a priori is actually very difficult
> 
> http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-
> numbers-2012-edition/
> 
> I would love to see a better qFuzzyCompare() implementation in Qt but the
> existing one is used in so many places it would be a nightmare to introduce
> without unwanted side effects.

I think it's not about mathematical correctness.
It's about deciding if something like width or height is updated or not.

So for those use-cases it's IMO enough to filter a lot/nearly all unnecessary 
updates out.

> 
> Cheers,
> 
> Sean
> 
> --
> Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] OpenGL in Qt 5.1 and onwards

[Thomas Senyk]

On Tue, December 18, 2012 19:28:23 Laszlo Papp wrote:
> On Tue, Dec 18, 2012 at 7:12 PM, Sean Harmer  wrote:
> > Something along those lines but also for Sampler objects where available
> > and higher level too e.g. A set of Texture Unit Configurations and also
> > that supports more features such as texture arrays (layered textures).
> 
> Ah, I have just realized we were discussing texture atlas as well that
> could be a reusable component, perhaps.

I agree.
A qml abstraction would be nice to have:

TextureAtlas {
default property list actions
}

This could be used for your icon-sets or your model-views, or similar.

Not sure if this helps performance that much .. and if it's easy to integrate 
into SG?

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

Re: [Development] qtwayland on i.mx6

[Thomas Senyk]

On Tue, January 08, 2013 21:23:54 Keller Alexander-B42067 wrote:
> I reverted back to the pervious version of qt5, but I still get this error.
> 
> Qt-Compositor configured with openGL integration: wayland_egl
> Project ERROR: Package egl not found

Their is a general assumption in all qtwayland that if pkgconfig is available, 
then their are also .pc files for everything (e.g. wayland_egl, egl, ...)

Me personally, I've never seen a embedded GPU-driver delivering egl.pc.
Their are even Qt/qmake variables to encounter for that.

Not sure how the case for wayland-egl is (not played with it on embedded yet),
but all the PKGCONFIG += ... egl ... within qtwayland look wrong to me.


Shouldn't config.test figure out what to do? ... 
 -> wayland_egl_pkgconfig tests if wayland-egl.pc is present.
 If not -> wayland_egl_direct tests if -lwayland-egl works
 
Based on those tests their is a .qmake.cache or something like that which sets 
all variables so no additional "PKGCONFIG += ..." or "-l..." are needed within 
.pro or .pri files.



Just me 5 cents!... It could be that I haven't taken a close enough look and 
that I'm inherently wrong ;)



Greets
Thomas


> 
> The EGL is install in the correct directory because when I check the
> config.log the egl package is found and passed the config test. Is there a
> variable that I need to set in order to make qtwayland grab the egl
> package?
> 
> -Alexander Keller
> 
> From: Nichols Andy [mailto:andy.nich...@digia.com]
> Sent: Tuesday, January 08, 2013 2:50 PM
> To: Keller Alexander-B42067
> Cc: development@qt-project.org
> Subject: RE: qtwayland on i.mx6
> 
> /home/alexander/qtwayland/src/compositor/compositor_api/compositor_api.pri:1
> 5: 'qtHaveModule' is not a recognized test function. Project ERROR: Package
> egl not found
> make[1]: *** [sub-compositor-install_subtargets] Error 3
> make[1]: Leaving directory `/home/alexander/qtwayland/src'
> make: *** [sub-src-install_subtargets] Error 2
> 
> This is caused by commit: 
> https://qt.gitorious.org/qt/qtwayland/commit/3758b0183e182007ac68fa74af9382
> 1a0353c5e6
> 
> This commit went in today, an unfortunately makes qtwayland incompatible
> with Qt 5.0.0 , but isn't really necessary yet, so you can revert it
> safely.
> 
> Regards,
> --
> Andy Nichols
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtGraphicalEffects

[Thomas Senyk]

Hi,

is anyone feeling somewhat responsible for QtGraphicalEffects?

I got 2 commit I would like to push.
It's not on codereview, is it?

(...by the way: where do I find a list of projects on codereview?)



Greets
Thomas


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

Re: [Development] QtGraphicalEffects

[Thomas Senyk]

On Tue, January 15, 2013 13:31:18 Nichols Andy wrote:
> Hi Thomas,
> 
> is anyone feeling somewhat responsible for QtGraphicalEffects?
> 
> I got 2 commit I would like to push.
> It's not on codereview, is it?
> 
> It is:
> https://codereview.qt-project.org/#q,project:qt/qtgraphicaleffects,n,z
> 
> 
> (...by the way: where do I find a list of projects on codereview?)
> 
> There is a list here(if you are able to access this):
> https://codereview.qt-project.org/#admin,projects


OK  that was easy ;) ... sorry for the dumb question, I never dared to 
click on the "Admin" button :D

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

Re: [Development] QtGraphicalEffects

[Thomas Senyk]

On Tue, January 15, 2013 14:32:52 Thomas Senyk wrote:
> On Tue, January 15, 2013 13:31:18 Nichols Andy wrote:
> > Hi Thomas,
> > 
> > is anyone feeling somewhat responsible for QtGraphicalEffects?
> > 
> > I got 2 commit I would like to push.
> > It's not on codereview, is it?
> > 
> > It is:
> > https://codereview.qt-project.org/#q,project:qt/qtgraphicaleffects,n,z
> > 
> > 
> > (...by the way: where do I find a list of projects on codereview?)
> > 
> > There is a list here(if you are able to access this):
> > https://codereview.qt-project.org/#admin,projects
> 
> OK  that was easy ;) ... sorry for the dumb question, I never dared to
> click on the "Admin" button :D


I found my mistake...
I got the one from:
https://gitorious.org/qt-labs/qtgraphicaleffects

I should have used:
https://qt.gitorious.org/qt/qtgraphicaleffects


Maybe someone should close the qt-labs repo?
(e.g. delete all files and leave a README pointing to the right repo)
... on the other hand I might be the only one not able to find the right repo 
right away ;)


Greets
Thomas


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

Re: [Development] FYI: non-approvers may now stage/submit

[Thomas Senyk]

On Thu, January 24, 2013 12:02:56 Oswald Buddenhagen wrote:
> moin,
> 
> it occurred to me that the inability of contributors to stage/submit
> their own changes ( https://bugreports.qt-project.org/browse/QTQAINFRA-303 )
> results merely from our stupidity, and not some technical problem. so after
> consultation with sergio i just changed it. at least i think so. ^^
> 
> the only "danger" i forsee is mindless re-staging upon integration
> failure. should this materialize, Measures Will Be Taken ™. but for the
> time being CI is too unreliable anyway and *everybody* is re-staging
> mindlessly ...
> 
> this also means that approvers have no excuse for being trigger-happy at
> all any more. leave staging to the author - he typically knows best in
> which order and when to submit stuff.
> 
> have fun

no more 'it failed somewhere else, could you please press the staging button 
again'-begging!

Thx! :)

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

[Development] integer bug in Qt4.8.x

[Thomas Senyk]

Hi,

I think I stumbled over a bug in Qt4.8.x - QtDeclarative, but I wanted to 
asked for opinions first.

First of all: This is not happening in Qt5 (neither QtQuick2.0 nor QtQuick 
1.1)

This seems to only happen on ARM... at least I couldn't reproduce on any x86 
machine I tried.
The ARM system I tested on:
  - imx6
  - yocto based rootfs, sysroot and toolchain
  - Qt5 built using mkspecs/devices/linux-imx6-g++ (not haven the bug)
  - Qt4 built with my own mkspec based on the Qt5 device-mkspec
  - Qt4/5 source-code from git with a most recent checkout



The bug:

It's about imprecise 'int' in QtQuick1.1 / JS (only Qt4!)
A code snipped triggering it would be:

property int ex: 0

Component.onCompleted:
{
var tmp;
var c = 1;

for ( tmp = ex + 1; /*forever*/; tmp++ )
{
if ( tmp !== ( ex + 1 ) )
{
console.log( "error: " + tmp + " != " + ex + " + 1" );
}

c = c+1;

if ( c > 10 )
{
console.log( tmp );
c = 1;
}

ex = tmp;
}

}


The log looks like:

...
820
830
error: 8388610 != 8388610 + 1
error: 8388612 != 8388612 + 1
error: 8388614 != 8388614 + 1
error: 8388616 != 8388616 + 1
...


where 8388610 == 0x82

For me it looks a little bit like some sort of floating-point accuracy 
problems ... or a casting-error ... ?


Greets
Thomas

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

Re: [Development] integer bug in Qt4.8.x

[Thomas Senyk]

On Wed, March 06, 2013 12:25:32 Samuel Rødal wrote:
> On 03/06/2013 11:38 AM, Thomas Senyk wrote:
> > Hi,
> > 
> > I think I stumbled over a bug in Qt4.8.x - QtDeclarative, but I wanted to
> > asked for opinions first.
> > 
> > First of all: This is not happening in Qt5 (neither QtQuick2.0 nor QtQuick
> > 1.1)
> > 
> > This seems to only happen on ARM... at least I couldn't reproduce on any
> > x86 machine I tried.
> > 
> > The ARM system I tested on:
> >- imx6
> >- yocto based rootfs, sysroot and toolchain
> >- Qt5 built using mkspecs/devices/linux-imx6-g++ (not haven the bug)
> >- Qt4 built with my own mkspec based on the Qt5 device-mkspec
> >- Qt4/5 source-code from git with a most recent checkout
> > 
> > The bug:
> > 
> > It's about imprecise 'int' in QtQuick1.1 / JS (only Qt4!)
> > A code snipped triggering it would be:
> > 
> > property int ex: 0
> > 
> > Component.onCompleted:
> > {
> > 
> >  var tmp;
> >  var c = 1;
> >  
> >  for ( tmp = ex + 1; /*forever*/; tmp++ )
> >  {
> >  
> >  if ( tmp !== ( ex + 1 ) )
> >  {
> >  
> >  console.log( "error: " + tmp + " != " + ex + " + 1" );
> >  
> >  }
> >  
> >  c = c+1;
> >  
> >  if ( c > 10 )
> >  {
> >  
> >  console.log( tmp );
> >  c = 1;
> >  
> >  }
> >  
> >  ex = tmp;
> >  
> >  }
> > 
> > }
> > 
> > 
> > The log looks like:
> > 
> > ...
> > 820
> > 830
> > error: 8388610 != 8388610 + 1
> > error: 8388612 != 8388612 + 1
> > error: 8388614 != 8388614 + 1
> > error: 8388616 != 8388616 + 1
> > ...
> > 
> > 
> > where 8388610 == 0x82
> > 
> > For me it looks a little bit like some sort of floating-point accuracy
> > problems ... or a casting-error ... ?
> > 
> > 
> > Greets
> > Thomas
> 
> Numbers in JavaScript are defined to be implemented as floating point.
> So I would expect the loop to end up printing error at some point.
> However, a JavaScript implementation is supposed to use double precision
> floating point numbers, in which case the loop would run for a really
> long time before printing out such an error (double can exactly
> represent all 32-bit integers).
> 
> However, with single precision floating point numbers you hit the
> problem a lot sooner, and this C program, using single precision
> floating point, shows the error happening at 16777216:
> 
> #include 
> int main(int argc, char **argv)
> {
>  volatile float value = 1;
>  volatile int v1, v2;
>  do {
>  v1 = value;
>  v2 = (float)(value + 1.0);
>  value = v2;
>  } while (v1 != v2);
>  printf("%d %d\n", v1, v1 / 2);
> }
> 
> So there's still something strange going on, since 16777216 is two times
> 8388608, which is where the error manifests in your example. Not sure
> what the explanation of that is, but at least I guess we can assume that
> the JavaScript engine used for QML in Qt 4 might use float (probably
> when qreal is float) and thus is not fully compliant.


I guess that's the answer/confirm I was looking for.

So -DQT_COORD_TYPE  could be one solution.
 ... although that would create more performance problems then using 'var' 
instead of 'int' for specific properties.

Thanks.

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

[Development] consistentTiming vs. wayland animation speed

[Thomas Senyk]

Hi,

when using qtwayland as client && server, then currently the animation speed 
is way too high (~6x what it should be on my machine)
 (got reported by at least one other person in #qt-lighthouse)

I've dug a little bit and found that:
   BufferQueueingOpenGL (QPlatformIntegration::Capability)
is enabled for wayland, which triggers:
   QUnifiedTimer::instance(true)->setConsistentTiming(true);
(see QQuickWindowManager::instance())

Which results in a fixed(!) 'delta' (animation progress 'time') of, in my case 
16, BUT the 'proceed'** isn't done every 16ms, but rather every ~1ms.

If using weston the 'proceed'** is called every ~10-12ms, which is still 
wrong, but way closer then ~1ms ... that's why weston looks ok but 
qtcompositor looks broken.

**QUnifiedTimer::updateAnimationTimers



I'm not sure where to problem originates from and how to fix it ...
My current guess is:
bool QQuickRenderThreadSingleContextWindowManager::event(QEvent *e)
with (e->type() == QEvent_Sync) is called way to often.

It should be called every 16ms (as close as possible) ... shouldn't it?


Can any elaborate what's the use-case for consistent-timing and how it's 
supposed to work?

Greets
Thomas

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

[Development] include

[Thomas Senyk]

Hi,

I'm just trying to build against a yocto based sysroot.
 - it doesn't contain X11 libs/headers
 - it contains libwayland  ... and in the end I want to build QtWayland 
against it

 => so I need xkbcommon
 => installing is no problem, because although it's a X11 package, it has no 
deps on X11 what so ever
 => when installed I get:
/home/tsenyk/qt5/qt5/qtbase/src/plugins/platforminputcontexts/compose/generator/qtablegenerator.cpp:54:24:
 
fatal error: X11/keysym.h: No such file or directory


... which IMO shouldn't be included there.
Looking at X11/keysym.h and X11/keysymdef.h if my desktop, I contains a lot of 
defines, all defines beginning with 'XK_'

but if I do:
tsenyk@rudolf:~/qt5/qt5/qtbase/src/plugins/platforminputcontexts/ grep -r XK_

I get nothing. I get some XKB_, but those are defined in xkbcommon/xkbcommon.h
... maybe the defines are different on older systems?
... maybe it's just a left over include?


So my question: is there something wrong with my logic or my conclusions?

If not: I assume I can push a change like: http://pastebin.com/NjBZpfAz
I've tested this on my desktop (archlinux 64bit) and for the target (yocto 
based sysroot, imx6 (arm)), both build without problems.



Question on the side: This is a commit for stable, right?
... It can be considered a "build-bug-fix"... or not?

Greets
Thomas





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