On 10/20/2017 12:49 AM, Filip Piechocki wrote:
On Oct 20, 2017 00:11, "Roland Hughes" <rol...@logikalsolutions.com
<mailto:rol...@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.
It's the most important segment of the market. Medical devices designed
to have up to 10 days of continuous use time (not stand by) while on
batteries. The things deployed to disaster areas
https://www.nbcnews.com/nightly-news/video/almost-80-percent-of-puerto-rico-still-without-power-1077278275904
https://www.washingtonpost.com/world/more-than-100-feared-buried-as-landslide-destroys-village-in-southwest-china/2017/06/23/fbec208e-5881-11e7-9e18-968f6ad1e1d3_story.html?utm_term=.c0d01e779851
http://www.cnn.com/2017/10/13/us/california-fires-updates/index.html
http://www.telegraph.co.uk/travel/destinations/caribbean/articles/hurricane-irma-hotels-open-island-damage/
If you really are using QML for phone applications thank you for
creating a generation of wall huggers who can't get more than a few
minutes away from the nearest power outlet. Your phones are sooooo
useful in Puerto Rico where many parts only get enough fuel to run the
generator for a couple of hours each week.
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.
No, I am not, QML is. Both Qt/Digia and others in here are pushing QML
as the solution to world hunger. A recent client sent developers to
Digia to be taught Qt. What did they get taught? QML and JSON files, not
a single 9*&)(*&)(*&ing mention of widgets or databases or the right way
to design a system. Guess what happened when they came back from
training? They tried to develop the entire embedded system using QML and
JSON files. A data acquisition and control system with many sensors
taking readings multiple times per second, storing them into a complex
directory tree of JSON files. Guess what? After a few hours of run time
the SD card for data storage went write protected because the time it
took to rewrite one of the JSON files after stuffing a new value into it
exceeded the device driver time out so the driver put the media into
write protection mode to save it.
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).
There is no need for QML, ever. In recent releases Digia/Qt has tried to
manufacture a "need" for it by choosing to implement certain features
only in the worthless QML.
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!
No. I'm showing them that this "solution to world hunger" being pushed
by the company and crazed eyed frothing at the mouth fanatics is the
incorrect solution in 99.9999999999999% of all situations yet _most_ of
them won't (*^)(*&)(*&ing bother to consider their platform because
_everyone_ talks about just how sexy QML is. Just because script kiddies
are cheap and just because it is being pushed by the vendor does not
mean it is a valid or even useful choice. Far too many companies are
hearing this "solution to world hunger" mantra, starting down the QML
path because that is all that is being taught and boom, product failure.
That reminds me, I need to follow up with a what is left of a company in
Indiana who went down the QML route. When I spoke with them several
years ago they were yet another group who believed they _had_ to use QML
as there was no other way. They were 9 months late, couldn't get it
working, looking for someone to "fix" the unfixable. Company had been in
business a long long time but heard they filed bankruptcy recently.
And thanks to the wiki page being done just as well as QML you can't
even cross compile most Qt applications.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
