[Interest] Interest Digest Wiki instructions for PI cross compile do not work for PostgreSQL support

Fri Oct 20 07:49:58 CEST 2017

On Oct 20, 2017 00:11, "Roland Hughes" <roland at logikalsolutions.com> wrote:

It's not misleading when it is a hog fattened way past market.

90% of the embedded systems I encounter have no GPU so the driver issue is
irrelevant. You get rid of all needless things to improve battery life.
Claiming an i.MX6 which most certainly must need grid power or batteries
the size of a house is the "normal" embedded processor for medical devices
or industrial control is simply ludicrous.

And how much of embedded market are devices you are talking about? 5%? 1%?
0.1%?

90% of embedded devices I encounter DO have GPU and these are TVs, set top
boxes, phones, public transport systems and even fridge. Oh, and using HW
parts that are specifically designed for some things (like GPUs are for
graphics) often gives much higher performance/(power draw). Of course it
depends how much you will use it.

I was using a Pi-II not a 1. The Pi-II has waaaaaaaaaaaaaaaaaaaay more
horsepower than the vast majority of embedded systems I'm talking about.

But it is still very weak CPU (I don't know the details but llvmpipe driver
might be limited by single core performance so not much difference between
RPi 1 and 2) and you are forcing it to draw OpenGL which this CPU would
like to not handle at all as it is not designed for this. Already shown
example of Qt Cinematic Experience which is much more sofisticated/fancy
than your example app and can run on decent frame rates on RPi 1. Like said
earlier - do this in widgets or whatever you like technology and compare
development time (so EFL is out...) and performance (so HTML5 is out...).
Oh, and you are wrong already in a second sentence of your blog post as one
can think that there is no difference between HTML/JS app and QtQuick app.
There is. I've run Servo browser engine benchmark limited to 60 items on
i.MX6 in chromium and got 8fps. Then redo this in QtQuick and got stable
60fps. That's 7.5x better. But this discussion makes me think that I need
to do this in widgets too. Any suggestions how?

Please do not mislead people. QML is a horrible wretched thing which should
never have seen the light of day.

If there is no need for it in your specific market - it is ok. In one of a
companies I worked we had huuuge desktop application done in Qt and I will
never suggest doing it in QtQuick as widgets are perfect choice for it. But
there are many solutions where there is need for technology like
QML/QtQuick, even if it is not perfect (and it is not).

Ok, so maybe you are not misleading people with your blog post - you're
just showing them that application that is not supposed to be done with
QtQuick which requires decent HW accelerated OpenGL since December 2012
(ok, it has changed recently but still hw accelerated graphics is what you
want) when done in QtQuick and ran on weak CPU and no HW OpenGL then
performs poorly. Wow. Thanks Captain Obvious! You could have asked me and I
will tell you the result without doing anything. But guess what - it has
nothing to do with JS engine in this particular example, so your statements
are wrong.

Offering up "The Microsoft Solution" of "throw hardware and grid power at
it" is simply no solution for the vast majority of embedded systems
especially in the medical field.

On 10/19/2017 02:04 PM, Filip Piechocki wrote:

On Thu, Oct 19, 2017 at 2:43 PM, Roland Hughes <roland at logikalsolutions.com>
wrote:

> Scroll down and watch the video. QML is an 800 lb gorilla trying to ride
> in a 2 cylinder car.
>
> http://www.logikalsolutions.com/wordpress/information-techno
> logy/raspberry-qt-part-12-qml-blows-big-stinky-chunks/
>

Application used here is of course the best candidate for widgets
implementation as it does not use QtQuick advantages.

Do this:
https://www.youtube.com/watch?v=wulbR2R1GpM
in Qt Widgets and share your results.

But please, do not mislead people. You run this app with software OpenGL on
a device with really weak CPU. Xorg alone eats all resources of RPi 1 as it
has no HW GPU acceleration.
In my company we get 20-25 fps when rendering maps on a quite powerful (for
embedded world) x86 and like 230% CPU usage (of 4 cores) as there is no
linux driver for its GPU. Meanwhile - we get stable 60fps on i.MX6 DualLite
(2 ARMv7 cores 792MHz) with 12-20% CPU usage. All done with QtQuick.

> Nasty worthless resource pig which exists only to pursue script kiddies.
>
> On 10/19/2017 04:38 AM, Vlad Stelmahovsky wrote:
>
> QML is not that resource hogging as JS. dont use JS and you'll be fine
>
> On Tue, Oct 17, 2017 at 8:11 PM, Roland Hughes <
> roland at logikalsolutions.com> wrote:
>
>>
>>
>> On 10/17/2017 12:54 PM, interest-request at qt-project.org wrote:
>>
>> On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland Hughes wrote:
>>
>> The bug tracking system is under our control - it will not just
>> disappear (from our perspective).
>>
>> Oh yes it will!
>>
>> Speaking as someone who has heard that soooooo many times before, let's
>> just count a few for Qt shall we.
>>
>> The Trolltech bug database was never going to just disappear (from our
>> perspective). It did. A tiny fraction of the bugs migrated to the new
>> system but most were mass exterminated with
>>
>> The TT TT was not a public database. It existed internally only. When we
>> switched to a public bugtracker, we could only export some entries since many
>> had confidential customer information. Those that were exported had to be
>> review by a person to make sure we were not violation any NDAs or
>> confidentiality.
>>
>> That's the same reason why the code repository starts with Qt 4.5, not earlier
>> versions.
>>
>>
>> "The version this bug is reported against is no longer supported..."
>>
>> The Nokia bug tracker was never going to just disappear (from our
>> perspective). It did. Few, if any of the older bugs made it into the
>> current database. Most were mass exterminated with
>>
>> There was no Nokia database. We switched straight from the internal tdb
>> (that's what it was called) to JIRA.
>>
>> There was a Nokia bug base as well, at least for a while. I and others
>> entered bugs into it back in the day. Your argument also re-enforces a
>> great many bugs "simply disappeared."
>>
>> I hear from quite a few companies in similar boats. They started
>> development for a medical/industrial device which had a lengthy
>> testing/approval process, filed bug reports for that version only to see
>> them rot or fall victim to a mass extermination.
>>
>> Most open source projects don't support old versions, since they don't have
>> the manpower to do so.
>>
>>
>> The current owners of Qt and the current OpenSource maintainers don't
>> offer or seem to understand the concept of an LTS (Long Term Support)
>> version. They are constantly pursuing script kiddies and that worthless
>> QML instead of maintaining the base which built them. This will soon
>> force a fork in the OpenSource project. One which rips out all of the
>> QML and focuses on nothing but bug fixes for 12 years. Yes, 12 years.
>>
>> Again, offence taken.
>>
>> Take all of the offense you want. Medical devices and industrial controls
>> need LTS versions, not resource hogging QML features. Qt's chasing of the
>> idiot phone market which has 6 months at best life spans is alienating and
>> chasing away the very industries which made Qt successful.
>>
>> I don't know who plans on forking. There's no such division in the community,
>> so any attempt to do so will probably start with very few developers. Almost
>> certainly, fewer than critical mass to maintain the codebase.
>>
>> See TQt (Trinity Project) for an example of a fork attempt.
>>
>> It's easy to fork something you have been maintaining internally for
>> years. There _IS_ such a division. You don't know about it because they
>> don't come here. They justifiably believe they've been abandoned. The
>> relentless pursuit of "new cool features" to please the phone crowd is
>> causing the much larger medical device and industrial control industries to
>> create their own LTS.
>>
>> How many questions have you seen on here over the past 18 months about Qt
>> 3? That project Harmman (sp?) calls about periodically sells north of a
>> million units per year and the company is maintaining Qt 3 on its own so
>> they can make minor product enhancements which don't have to go though
>> multi-year clinical trials. They aren't the only calls I get about products
>> using Qt 3, 4.2, and the most likely soon to be orphaned (if not already)
>> 4.8. Every company I am contacted about using earlier versions has their
>> own staff maintaining the code base today. They have had no other choice.
>> If anything, joining forces with someone who is not a competitor but using
>> the same tool set will lighten their load.
>>
>> --
>> Roland Hughes, President
>> Logikal Solutions(630)-205-1593 <%28630%29%20205-1593>
>> http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/bloghttp://lesedi.us/http://onedollarcontentstore.com
>>
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>
>
> --
> Best regards,
> Vlad
>
>
> --
> Roland Hughes, President
> Logikal Solutions(630)-205-1593 <%28630%29%20205-1593>
> http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/bloghttp://lesedi.us/http://onedollarcontentstore.com
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>

-- 
Roland Hughes, President
Logikal Solutions(630)-205-1593 <(630)%20205-1593>
http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/bloghttp://lesedi.us/http://onedollarcontentstore.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20171020/af2aec02/attachment.html>