Alpha4 release status

Tue Jun 19 05:27:18 UTC 2012

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.

On Sun, Jun 17, 2012 at 3:58 AM, BogDan Vatra <taipanromania at gmail.com>wrote:

> 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...
> >> >
> >> >
>

-- 
Tyler Mandry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20120618/c0afa9e7/attachment-0001.html>