I've created much more complex apps using QtQuick 1 on HW much weaker than RPi2 (Symbian phones) w/o such laggin as in this simple calc example. Obviously, there something wrong with code and/or system setup
On Fri, Oct 20, 2017 at 7:49 AM, Filip Piechocki <fpiecho...@gmail.com> wrote: > > > On Oct 20, 2017 00:11, "Roland Hughes" <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. > > 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 < > rol...@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 < >> rol...@logikalsolutions.com> wrote: >> >>> >>> >>> On 10/17/2017 12:54 PM, interest-requ...@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@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@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 > > > -- Best regards, Vlad
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest