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?<div><br></div><div>Just clarifying :) Thanks for all your hard work.<br>
<br><div class="gmail_quote">On Sun, Jun 17, 2012 at 3:58 AM, BogDan Vatra <span dir="ltr"><<a href="mailto:taipanromania@gmail.com" target="_blank">taipanromania@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello everyone,<br>
<br>
I have some good and bad news.<br>
<br>
I changed the atomics in order to make the safe, I chose the fifth<br>
approach and it seems they are just a little bit slower, because it<br>
has to do an extra function call. The good news are there is no ABI<br>
break, so I can still play my favorite GPLv3 Qt game which I bought it<br>
a few months ago :). No, I'm not crazy :)! I bought a GPLv3 game<br>
because I like it! It also helped me a lot to test alpha4 branch. The<br>
bad news is that the application start up is still slower comparing<br>
with alpha3, this is because I've done a little hack in android assets<br>
implementation to keep the compatibility with alpha3. But if the<br>
assets access will be updated to alpha4, the start up is almost the<br>
same. I'm not going to fix this problem now, because I don't have<br>
enough time, after alpha4 is out, we'll focus on performance and<br>
bugfixes only.<br>
<br>
<br>
Cheers,<br>
BogDan.<br>
<br>
<br>
2012/6/15 Tyler Mandry <<a href="mailto:tmandry@gmail.com">tmandry@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> I say try 5) and benchmark it.<br>
><br>
> I understand that you're trying to keep backward compatibility, but for such<br>
> fundamental and important changes, IMO it is far better to break the ABI now<br>
> than to pay for it in the future. Besides, we are still in alpha, breaking<br>
> the ABI should be considered a regular occurrence ;)<br>
><br>
><br>
> On Sunday, June 10, 2012 12:15:12 PM UTC-7, BogDan wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Many thanks for kind words !<br>
>><br>
>> Sadly, the magic happened :). The good news is that it was my fault,<br>
>> the bad news it that my worst nightmare happened ... :(<br>
>> After I write my first mail I begin to cherry-pick all my changes from<br>
>> alpha4 and put them on top of alpha3 branch, then I spot a patch which<br>
>> caught my attention, and I really hoped it's not the cause of this<br>
>> problem, but it was ...<br>
>> Some time ago somebody complained on this mailing list about the fact<br>
>> that he could not be able to compile necessitas anymore using ndk-r7,<br>
>> soon I discovered that the atomics functions where not exported<br>
>> anymore in ndk-r7, then my nightmare began, first I post the problem<br>
>> on android-ndk mailing list[1], then Google suggest me that I should<br>
>> switch to gcc's built in atomics which I did[2]. I knew that the gcc<br>
>> built in atomics are not the fastest in the world, but I never thought<br>
>> that they are that bad. Android atomics support on necessitas is a<br>
>> long story, which began more than a year ago, I'll try to make it<br>
>> shorter for you :)<br>
>> For the very first android atomics implementation, I used Qt's arm<br>
>> atomics, but I had to switch to gcc built-in atomics (yes, the second<br>
>> implementation was based on gcc atomics) because Qt's arm5 atomics<br>
>> where useless for Android, I'll try to explain why: The problem is<br>
>> that Qt's arm5 atomics are not SMP safe, so, is probable that your app<br>
>> will crash on a dual-core device. arm5 is very important because it is<br>
>> supported by all arm android devices, so it must be SMP safe. I<br>
>> address this problem last year at QCS[3], and somebody offer to help,<br>
>> but sadly nothing happened. So, I had to find a solution myself, GCC's<br>
>> implementation is using a sort of memory barrier (a mutext or<br>
>> something) to make it SMP safe, that why is so slow, then I discover<br>
>> that google is providing atomics in libc, which they should be SMP<br>
>> safe, so I switched to android atomics, then google change their mind<br>
>> and now they are dropping the support, so I had to switch back to gcc.<br>
>><br>
>> To "fix" this problem I see the following "solutions":<br>
>> 1. Ignore Google warning and keep using android atomics.<br>
>> 2. Stay with gcc atomics, but is too slow.<br>
>> 3. Build Qt libs with fast atomics, but find a way to have safe<br>
>> atomics for arm5.<br>
>> 4. Build Qt libs with fast atomics, but use GCC atomics for apps.<br>
>> 5. Build Qt libs with fast atomics, but don't make qt atomics inline<br>
>> anymore, this way your apps will use what qt provides for that<br>
>> platform. They will be a little by slower but they should be safe.<br>
>> This is my favorite solution, but I afraid that it will break the ABI<br>
>> ...<br>
>><br>
>> It is safe to build Qt libs with fast atomics for arm5 because arm5<br>
>> libs will be downloaded Ministro *only* on arm5 devices and AFAIK<br>
>> there is no SMP arm5 device. The problem is that your apps are not<br>
>> downloaded by Ministro :) and if they are built only using armv5 they<br>
>> will be loaded by a SMP device and they will have problems, so arm5<br>
>> atomics must be SMP safe.<br>
>><br>
>> Anyway we have to address the problem once and for all !<br>
>><br>
>> If any of you has any other Ideas please don't hesitate to share them with<br>
>> us.<br>
>> Also any comments/feedback will be very appreciated.<br>
>><br>
>> Cheers,<br>
>> BogDan.<br>
>><br>
>><br>
>> [1]<br>
>> <a href="https://groups.google.com/group/android-ndk/browse_thread/thread/a792d8392b01f389/ecbad8bb4981ed8d" target="_blank">https://groups.google.com/group/android-ndk/browse_thread/thread/a792d8392b01f389/ecbad8bb4981ed8d</a><br>
>> [2]<br>
>> <a href="http://commits.kde.org/android-qt/aa14a65fd29f20adb7aa22b354c975d76266bed1" target="_blank">http://commits.kde.org/android-qt/aa14a65fd29f20adb7aa22b354c975d76266bed1</a><br>
>> [3] <a href="http://community.kde.org/Necessitas/Meetings/QtCS2011" target="_blank">http://community.kde.org/Necessitas/Meetings/QtCS2011</a><br>
>><br>
>><br>
>> 2012/6/10 Bruno Zerbo <<a href="mailto:bruno.zerbo@gmail.com">bruno.zerbo@gmail.com</a>>:<br>
>> > Thanks BogDan for your work.<br>
>> > cheers,<br>
>> > Bruno<br>
>> ><br>
>> ><br>
>> > 2012/6/10 BogDan Vatra <<a href="mailto:taipanromania@gmail.com">taipanromania@gmail.com</a>><br>
>> >><br>
>> >> Hello folks,<br>
>> >><br>
>> >> Unfortunately I have more bad news regarding alpha4 release, I<br>
>> >> manage to fix the OpenGL problem, but I discover another one. The<br>
>> >> startup of all applications has slowdown a lot (2-4 times), the<br>
>> >> problem is the difference between alpha3 and alpha4 is huge (1000+<br>
>> >> patches). Alpha3 is based on Qt 4.8.0-rc and alpha4 is based on Qt<br>
>> >> 4.8.2, to be sure the problem is not caused by me, I have to<br>
>> >> cherry-pick all my changes and put them on top of alpha3, them, if is<br>
>> >> not my fault the pain begins, I'll have to merge Qt 4.8.0, check, then<br>
>> >> Qt 4.8.1, then Qt 4.8.2. This is going to be a very slow and painful<br>
>> >> process which will take days (even weeks) so, I don't believe alpha4<br>
>> >> will be out before QCS, unless a miracle happens and I'll found the<br>
>> >> issue in the next days.<br>
>> >><br>
>> >> Sorry for the bad news ...<br>
>> >><br>
>> >> Cheers,<br>
>> >> BogDan.<br>
>> >><br>
>> >><br>
>> >> 2012/6/4 BogDan <<a href="mailto:taipanromania@gmail.com">taipanromania@gmail.com</a>>:<br>
>> >> > This <a href="http://files.kde.org/necessitas/installer/MinistroActivity.apk" target="_blank">http://files.kde.org/necessitas/installer/MinistroActivity.apk</a><br>
>> >> > is<br>
>> >> > the link to Ministro.<br>
>> >> ><br>
>> >> > BogDan.<br>
>> >> ><br>
>> >> ><br>
>> >> > On Jun 4, 2:02 pm, BogDan Vatra <<a href="mailto:taipanroma...@gmail.com">taipanroma...@gmail.com</a>> wrote:<br>
>> >> >> Hi everyone,<br>
>> >> >><br>
>> >> >> As you may know the alpha4 release is approaching, the plan is to<br>
>> >> >> have it ready before Qt Contributors Summit. It is almost completed,<br>
>> >> >> I<br>
>> >> >> need a few days to polish the style plugin and Minitro and another<br>
>> >> >> few<br>
>> >> >> to add support for context menus.<br>
>> >> >><br>
>> >> >> A few days ago I pushed to Minnistro's "unstable" repository the<br>
>> >> >> current alpha4 branch in order to check if the existing released<br>
>> >> >> apps<br>
>> >> >> are still working. Even we've made some heavy changes and even if I<br>
>> >> >> warn you that it may break the compatibility with older versions, I<br>
>> >> >> wanted alpha4 to be backward compatible with alpha3, it is also a<br>
>> >> >> test<br>
>> >> >> for Necessitas developers to see if we can keep our promise: to ship<br>
>> >> >> releases which are backward compatible!<br>
>> >> >><br>
>> >> >> If you want to try it yourself please follow the next two steps:<br>
>> >> >> - uninstall official Ministro and use this<br>
>> >> >> onehttp://<a href="http://files.kde.org/necessitas/MinistroActivity.apk" target="_blank">files.kde.org/necessitas/MinistroActivity.apk</a>.<br>
>> >> >> - install and run Ministro configuration tool (from market) and<br>
>> >> >> choose unstable repository.<br>
>> >> >><br>
>> >> >> Don't forget that Ministro is not stable and it may crash/hang, if<br>
>> >> >> you<br>
>> >> >> encounter any problems please reply on this thread.<br>
>> >> >><br>
>> >> >> Shorty after the repository was ready, I tried a few apps from<br>
>> >> >> market<br>
>> >> >> and two major problems pop up:<br>
>> >> >> - The first problem was related to some missing symbols and was<br>
>> >> >> caused<br>
>> >> >> by compilation/linking flags.<br>
>> >> >> - The second one is related to OpenGL and it seems to be caused by<br>
>> >> >> the<br>
>> >> >> merge with Qt 4.8.2.<br>
>> >> >><br>
>> >> >> 1. Missing symbols problem: Android comes with almost no support for<br>
>> >> >> C++, so to compile Qt we used (static) gnu-libstdc++.<br>
>> >> >> Then I discovered that this was a big mistake (for more information<br>
>> >> >> check Android NDK docs/CPLUSPLUS-SUPPORT.html "II.3. Static<br>
>> >> >> runtimes:"<br>
>> >> >> section).<br>
>> >> >> We can not use link libstdc++ statically if we are using more than<br>
>> >> >> one<br>
>> >> >> shared libraries in a project. To fix this problem I had two<br>
>> >> >> choices:<br>
>> >> >> - to use the shared libstdc++ implementation and to change all the<br>
>> >> >> scripts in order to add it to ministro (1.2M).<br>
>> >> >> - to "embed" the whole library into QtCore library (it adds and<br>
>> >> >> extra<br>
>> >> >> 600K) but this change requires no additional changes.<br>
>> >> >><br>
>> >> >> I choose the second one [1],[2] because it was safe and easy and<br>
>> >> >> mostly because it didn't needed any other changes.<br>
>> >> >> If anybody has something against this change speak now or forever<br>
>> >> >> hold<br>
>> >> >> your peace !<br>
>> >> >><br>
>> >> >> I'd like to add exceptions and RTTI by default, if the size and<br>
>> >> >> speed<br>
>> >> >> will not be affected.<br>
>> >> >><br>
>> >> >> 2. OpenGL problem: After I merged alpha4 branch with upstream Qt<br>
>> >> >> 4.8.2, most of the OpenGL apps are not working anymore, I tried to<br>
>> >> >> fix<br>
>> >> >> it my self but I end up with a very ugly workarround. It seems that<br>
>> >> >><br>
>> >> >><br>
>> >> >> "boolQGLContext::areSharing(constQGLContext*context1,constQGLContext*contex<br>
>> >> >> t2)"<br>
>> >> >> always returns false. I tried to trace the problem but with no luck<br>
>> >> >> and I end up adding a super dirty workarround: on android,<br>
>> >> >> "QGLContext::areSharing", will always returns true. I really don't<br>
>> >> >> like it, so until we'll figure out what is wrong the release process<br>
>> >> >> will stop ...<br>
>> >> >><br>
>> >> >> Any help will on this matter be very appreciated !<br>
>> >> >><br>
>> >> >> I've spot another minor problem with old assets support it was<br>
>> >> >> caused<br>
>> >> >> by "QString QDeclarativeTypeLoader::absoluteFilePath(const QString<br>
>> >> >> &path)" I fixed it locally but I didn't had time to push the fix to<br>
>> >> >> Minsitro's repository yet.<br>
>> >> >> I'll keep you post with the progress and with any Ministro<br>
>> >> >> repository<br>
>> >> >> changes.<br>
>> >> >><br>
>> >> >> Cheers,<br>
>> >> >> BogDan.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> [1]<a href="http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=8c4c862." target="_blank">http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=8c4c862.</a>..<br>
>> >> >><br>
>> >> >><br>
>> >> >> [2]<a href="http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=abe85f4." target="_blank">http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=abe85f4.</a>..<br>
>> ><br>
>> ><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tyler Mandry<br>
</div>