Alpha4 release status

[BogDan Vatra]

Hi everyone,

As you may know the alpha4 release is approaching, the plan is to
have it ready before Qt Contributors Summit. It is almost completed, I
need a few days to polish the style plugin and Minitro and another few
to add support for context menus.

A few days ago I pushed to Minnistro's "unstable" repository the
current alpha4 branch in order to check if the existing released apps
are still working. Even we've made some heavy changes and even if I
warn you that it may break the compatibility with older versions, I
wanted alpha4 to be backward compatible with alpha3, it is also a test
for Necessitas developers to see if we can keep our promise: to ship
releases which are backward compatible!

If you want to try it yourself please follow the next two steps:
- uninstall official Ministro and use this one
http://files.kde.org/necessitas/MinistroActivity.apk.
- install and run Ministro configuration tool (from market) and
choose unstable repository.

Don't forget that Ministro is not stable and it may crash/hang, if you
encounter any problems please reply on this thread.

Shorty after the repository was ready, I tried a few apps from market
and two major problems pop up:
- The first problem was related to some missing symbols and was caused
by compilation/linking flags.
- The second one is related to OpenGL and it seems to be caused by the
merge with Qt 4.8.2.


1. Missing symbols problem: Android comes with almost no support for
C++, so to compile Qt we used (static) gnu-libstdc++.
Then I discovered that this was a big mistake (for more information
check Android NDK docs/CPLUSPLUS-SUPPORT.html "II.3. Static runtimes:"
section).
We can not use link libstdc++ statically if we are using more than one
shared libraries in a project. To fix this problem I had two choices:
- to use the shared libstdc++ implementation and to change all the
scripts in order to add it to ministro (1.2M).
- to "embed" the whole library into QtCore library (it adds and extra
600K) but this change requires no additional changes.

I choose the second one [1],[2] because it was safe and easy and
mostly because it didn't needed any other changes.
If anybody has something against this change speak now or forever hold
your peace !

I'd like to add exceptions and RTTI by default, if the size and speed
will not be affected.

2. OpenGL problem: After I merged alpha4 branch with upstream Qt
4.8.2, most of the OpenGL apps are not working anymore, I tried to fix
it my self but I end up with a very ugly workarround. It seems that
"boolQGLContext::areSharing(constQGLContext*context1,constQGLContext*context2)"
always returns false. I tried to trace the problem but with no luck
and I end up adding a super dirty workarround: on android,
"QGLContext::areSharing", will always returns true. I really don't
like it, so until we'll figure out what is wrong the release process
will stop ...

Any help will on this matter be very appreciated !

I've spot another minor problem with old assets support it was caused
by "QString QDeclarativeTypeLoader::absoluteFilePath(const QString
&path)" I fixed it locally but I didn't had time to push the fix to
Minsitro's repository yet.
I'll keep you post with the progress and with any Ministro repository changes.

Cheers,
BogDan.


[1] http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=8c4c862ee26283d1f4cd698071d002577aff72df
[2] http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=abe85f41bd892a9948dda1fd8d124878c5bf37ab

[BogDan]

This http://files.kde.org/necessitas/installer/MinistroActivity.apk is
the link to Ministro.

BogDan.

On Jun 4, 2:02 pm, BogDan Vatra <taipanroma...@gmail.com> wrote:
> Hi everyone,
>
>  As you may know the alpha4 release is approaching, the plan is to
> have it ready before Qt Contributors Summit. It is almost completed, I
> need a few days to polish the style plugin and Minitro and another few
> to add support for context menus.
>
>   A few days ago I pushed to Minnistro's "unstable" repository the
> current alpha4 branch in order to check if the existing released apps
> are still working. Even we've made some heavy changes and even if I
> warn you that it may break the compatibility with older versions, I
> wanted alpha4 to be backward compatible with alpha3, it is also a test
> for Necessitas developers to see if we can keep our promise: to ship
> releases which are backward compatible!
>
> If you want to try it yourself please follow the next two steps:

>  - uninstall official Ministro and use this onehttp://files.kde.org/necessitas/MinistroActivity.apk.

> [1]http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=8c4c862...
> [2]http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=abe85f4...

[BogDan Vatra]

Hello folks,

Unfortunately I have more bad news regarding alpha4 release, I
manage to fix the OpenGL problem, but I discover another one. The
startup of all applications has slowdown a lot (2-4 times), the
problem is the difference between alpha3 and alpha4 is huge (1000+
patches). Alpha3 is based on Qt 4.8.0-rc and alpha4 is based on Qt
4.8.2, to be sure the problem is not caused by me, I have to
cherry-pick all my changes and put them on top of alpha3, them, if is
not my fault the pain begins, I'll have to merge Qt 4.8.0, check, then
Qt 4.8.1, then Qt 4.8.2. This is going to be a very slow and painful
process which will take days (even weeks) so, I don't believe alpha4
will be out before QCS, unless a miracle happens and I'll found the
issue in the next days.

Sorry for the bad news ...

Cheers,
BogDan.


2012/6/4 BogDan <taipan...@gmail.com>:

[Adam Pigg]

Thanks for the update, i hope you get reimbursed for this great work!

[Bruno Zerbo]

Thanks BogDan for your work.
cheers,
Bruno

2012/6/10 BogDan Vatra <taipan...@gmail.com>

[BogDan Vatra]

Hi,

Many thanks for kind words !

Sadly, the magic happened :). The good news is that it was my fault,
the bad news it that my worst nightmare happened ... :(
After I write my first mail I begin to cherry-pick all my changes from
alpha4 and put them on top of alpha3 branch, then I spot a patch which
caught my attention, and I really hoped it's not the cause of this
problem, but it was ...
Some time ago somebody complained on this mailing list about the fact
that he could not be able to compile necessitas anymore using ndk-r7,
soon I discovered that the atomics functions where not exported
anymore in ndk-r7, then my nightmare began, first I post the problem
on android-ndk mailing list[1], then Google suggest me that I should
switch to gcc's built in atomics which I did[2]. I knew that the gcc
built in atomics are not the fastest in the world, but I never thought
that they are that bad. Android atomics support on necessitas is a
long story, which began more than a year ago, I'll try to make it
shorter for you :)
For the very first android atomics implementation, I used Qt's arm
atomics, but I had to switch to gcc built-in atomics (yes, the second
implementation was based on gcc atomics) because Qt's arm5 atomics
where useless for Android, I'll try to explain why: The problem is
that Qt's arm5 atomics are not SMP safe, so, is probable that your app
will crash on a dual-core device. arm5 is very important because it is
supported by all arm android devices, so it must be SMP safe. I
address this problem last year at QCS[3], and somebody offer to help,
but sadly nothing happened. So, I had to find a solution myself, GCC's
implementation is using a sort of memory barrier (a mutext or
something) to make it SMP safe, that why is so slow, then I discover
that google is providing atomics in libc, which they should be SMP
safe, so I switched to android atomics, then google change their mind
and now they are dropping the support, so I had to switch back to gcc.

To "fix" this problem I see the following "solutions":
1. Ignore Google warning and keep using android atomics.
2. Stay with gcc atomics, but is too slow.
3. Build Qt libs with fast atomics, but find a way to have safe
atomics for arm5.
4. Build Qt libs with fast atomics, but use GCC atomics for apps.
5. Build Qt libs with fast atomics, but don't make qt atomics inline
anymore, this way your apps will use what qt provides for that
platform. They will be a little by slower but they should be safe.
This is my favorite solution, but I afraid that it will break the ABI
...

It is safe to build Qt libs with fast atomics for arm5 because arm5
libs will be downloaded Ministro *only* on arm5 devices and AFAIK
there is no SMP arm5 device. The problem is that your apps are not
downloaded by Ministro :) and if they are built only using armv5 they
will be loaded by a SMP device and they will have problems, so arm5
atomics must be SMP safe.

Anyway we have to address the problem once and for all !

If any of you has any other Ideas please don't hesitate to share them with us.
Also any comments/feedback will be very appreciated.

Cheers,
BogDan.


[1] https://groups.google.com/group/android-ndk/browse_thread/thread/a792d8392b01f389/ecbad8bb4981ed8d
[2] http://commits.kde.org/android-qt/aa14a65fd29f20adb7aa22b354c975d76266bed1
[3] http://community.kde.org/Necessitas/Meetings/QtCS2011


2012/6/10 Bruno Zerbo <bruno...@gmail.com>:

[Adam Pigg]

Well, the one app i have published is only for armv7 atm, due to bugs
161 and 162 on armv5, so im happy with whatever :)

[BogDan Vatra]

I really don't see the connection between these bugs and armv5 architecture ...

BogDan.

2012/6/10 Adam Pigg <pig...@gmail.com>:

[Adam Pigg]

Quite possibly, but.....could it be something in ministro that is
causing the libs not to download? becuase, when i deploy/use the qt
libs from the IDE, it works fine.

Thanks

[Tyler Mandry]

I say try 5) and benchmark it.

I understand that you're trying to keep backward compatibility, but for such fundamental and important changes, IMO it is far better to break the ABI now than to pay for it in the future. Besides, we are still in alpha, breaking the ABI should be considered a regular occurrence ;)

[BogDan Vatra]

Hello everyone,

I have some good and bad news.

I changed the atomics in order to make the safe, I chose the fifth
approach and it seems they are just a little bit slower, because it
has to do an extra function call. The good news are there is no ABI
break, so I can still play my favorite GPLv3 Qt game which I bought it
a few months ago :). No, I'm not crazy :)! I bought a GPLv3 game
because I like it! It also helped me a lot to test alpha4 branch. The
bad news is that the application start up is still slower comparing
with alpha3, this is because I've done a little hack in android assets
implementation to keep the compatibility with alpha3. But if the
assets access will be updated to alpha4, the start up is almost the
same. I'm not going to fix this problem now, because I don't have
enough time, after alpha4 is out, we'll focus on performance and
bugfixes only.


Cheers,
BogDan.


2012/6/15 Tyler Mandry <tma...@gmail.com>:

[Tyler Mandry]

So, if we use the new assets:/ schema, do we get all the performance improvements? Or, do other changes still need to be done to the library to get performance improvements?

Just clarifying :) Thanks for all your hard work.

--
Tyler Mandry