Alpha4 release status

[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 <tmandry at gmail.com>:
> 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 ;)
>
>
> On Sunday, June 10, 2012 12:15:12 PM UTC-7, BogDan wrote:
>>
>> 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.zerbo at gmail.com>:
>> > Thanks BogDan for your work.
>> > cheers,
>> > Bruno
>> >
>> >
>> > 2012/6/10 BogDan Vatra <taipanromania at gmail.com>
>> >>
>> >> 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 <taipanromania at gmail.com>:
>> >> > This http://files.kde.org/necessitas/installer/MinistroActivity.apk
>> >> > is
>> >> > the link to Ministro.
>> >> >
>> >> > BogDan.
>> >> >
>> >> >
>> >> > On Jun 4, 2:02 pm, BogDan Vatra <taipanroma... at 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.
>> >> >>  - 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*contex
>> >> >> t2)"
>> >> >> 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=8c4c862...
>> >> >>
>> >> >>
>> >> >> [2]http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=abe85f4...
>> >
>> >