Laszlo,

1) It's QML. Massive stinky pig which is __ALWAYS__ the wrong choice for any project.

2) EGLFS is how we got here. The Wiki instructions are pure excrement for anything more complex than "Hello World."

But that's fine because the bug report for the Wiki instructions has been "Resolved" without any action taken. It sits out there spawning countless other Wiki and blog posts all based on broken instructions.

https://www.youtube.com/watch?v=MAfCQ-t7xY0



On 10/19/2017 07:57 AM, Laszlo Agocs wrote:

Perhaps because it could be running with a pure software OpenGL implementation (Mesa llvmpipe) which Raspbian and friends tend to use to provide OpenGL on X11. (at least until VC4 becomes the default; in the meantime acceleration is limited to when running directly on Dispmanx, hence our general recommendation of using eglfs on embedded boards in order to cut out the potentially problematic middle layers)

If that’s the case, then the performance issues showcased here have nothing to with QML, Qt Quick or anything Qt really. Run with QSG_INFO=1 to verify.

Cheers,

Laszlo

*From:*Interest [mailto:interest-bounces+laszlo.agocs=qt...@qt-project.org] *On Behalf Of *Roland Hughes
*Sent:* torsdag 19. oktober 2017 14.43
*To:* Vlad Stelmahovsky <vladstelmahov...@gmail.com>
*Cc:* interest <interest@qt-project.org>
*Subject:* Re: [Interest] Interest Digest Wiki instructions for PI cross compile do not work for PostgreSQL support

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-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/

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 <mailto:rol...@logikalsolutions.com>>
    wrote:

        On 10/17/2017 12:54 PM, interest-requ...@qt-project.org
        <mailto: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

        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 <mailto:Interest@qt-project.org>
        http://lists.qt-project.org/mailman/listinfo/interest



--
    Best regards,

    Vlad



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

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

Reply via email to