Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: >If you are *so* resouce constrained, use LVGL.Â
You're probably not using 15MB Qt llibraries anyway, and they wouldÂ
take too long load anyway.
Oh, we do. It's only the dynamic allocations. Initial allocation as
determined
by the loader, taking one big block, is fine or at least it always has been.
Content analysis details: (4.8 points, 4.6 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.182.201.150 listed in wl.mailspike.net]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: logikalsolutions.com]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
3.3 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[50.201.197.204 listed in zen.spamhaus.org]
0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
2.5 FAKE_REPLY_A1 No description available.
--- Begin Message ---
>If you are *so* resouce constrained, use LVGL. You're probably not using 15MB
Qt llibraries anyway, and they would take too long load anyway.
Oh, we do. It's only the dynamic allocations. Initial allocation as
determined by the loader, taking one big block, is fine or at least it
always has been.
Putting it in perspective for you.
The UI artists were providing one SVG file per screen. That file had all
of the images for said screen. We had to pull each image out. Initially,
because it was there, the section pre-loading images for BLITting just
cached all of them from the file before moving on. One of the developers
changed this early on to load alphabetically. We started getting more
and more images. On the desktop things loaded in under 3 seconds so
nobody cared. Cold boot on target was 40-45 minutes.
Changing the code to load all images from an SVG file before moving on
dropped cold boot to under 5 minutes. (I want to say 3.) Still too long,
but night and day different.
On the desktop we didn't notice any real difference.
Creating objects for all of the XML inside of the SVG was a lot of
dynamic memory allocation in tiny units.
--
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
--- End Message ---
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
