I am getting a error when sending an app to the build server to create a UWP build:
[exec] (_ValidateAppxPackage target) ->
[exec] Package.appxmanifest(19,26): error APPX3207: App manifest references the wide 310x150 logo image 'Assets\Wide310x150Logo.scale-200.png' which is larger than the maximum image file size. It must be no larger than 204,800 bytes.
The app's logo is the required size (512x512) so I am a bit perplexed. Any help would be appreciated. TIA.
I have found the cause. When Codename One resizes the app icon from the provided size of 512x512 to 310x150 it doesn't seem to reduce the file size at all. As my original icon was (just) over 200Kb the smaller version was also over the limit. I have optimised my icon's PNG file and now the build succeeds.
Related
I have this project: https://github.com/crinklywrappr/repoman
It's very short (~150loc). When I run lein native-image it produces a massive 4gb3gb binary (at least on windows).
I believe there are a couple of reasons for the size:
--allow-incomplete-classpath is required due to an error compiling clj-http-lite. (this may have fixed it) Including this commit reduced the size by 1gb.
JCA security services adds some size, and the devs are looking into ways of reducing that.
I've never made a native image with graal before today. What steps can be taken to reduce the binary size of a graal native image?
It turns out that the graal was reporting memory consumption during compilation, and I was mis-attributing that to filesize.
I've been searching for days about this issue and didn't find any solved thread.
I need loading pretty large images (4 GB and beyond, either .tiff / .png) into openCV code, by means of a simple
src = imread(filepath, 1);
I'm using Visual Studio 2013, C++.
Though I'm using a 96Gb-RAM machine, runtime alerts are coming out when loading these large images by OpenCV's "imread" function. Been trying with smaller and smaller images/files untill the point they are indeed read/loaded, so we know it's a matter of memory/allocation since smaller images are correctly loaded and processed.
Console is throughing the following message, extracted by "catch (...)"
OpenCV Error: One of arguments' values is out of range (The total
matrix size does not fit to "size_t" type) in cv::setSize, file
C:\builds\2_4_PackSlave-win32-
vc12-shared\opencv\modules\core\src\matrix.cpp, line 126
On the other hand, VS2013 shows the following alert while running (no compilation issues at all):
Unhandled exception at 0x76385608 in poblacion.exe: Microsoft C++
exception: cv::Exception at memory location 0x00C7EA70
also arguing "no symbols loaded". We are compiling in Win32, Debug mode.
This issue is bug #3258 but no solved thread is found out there, just discussion regarging size_t type leading to no clear solution... There should be a way of reading large images without going through openCV libraries...
Did this happen to anybody there who can help us?? I will spread any satifying solution.
THANX in advance!
Alex
size_t size differs between Win32 and x64 platforms. Error tells that matrix dimensions do not fit in size_t type.
Consider switching to x64 configuration and your problem should disappear.
In addition to that, Win32 configuration is not suitable for applications which are expected to use >4GB of RAM per process.
That means you will not be able to use the full power of your machine with 96GB RAM running Win32 application.
I'm developing a Windows game that needs a lot of small different images, that I put in resources.qrc, they are in tot. 14 MB.
When I try to compile the only error is: "out of memory allocating 134 MB" "cc1plus.exe not found".
How can I handle this?
Windows 7SP1 x86 4 GB RAM
Qt 5.7.0
I had the same problem, when I added big file in resources in Qt. I had the error:
cc1plus.exe:-1: error: out of memory allocating 1073745919 bytes
Solution:
Add CONFIG += resources_big into the *.pro file.
I took it here: cc1plus.exe: out of memory | 60MB encrypted resource file
Don't put them in the qrc, keep them as individual resources (or a new qrc file for each of the image), and just load them on application startup. Qt generates a qrc_XXXXX.cpp file where it effectively inserts the binary data in form of char array of ALL your resources in the resource fileXXXXX in this file (yes, ONE array for your images of 14MB, ie: 14680064 bytes (written as hex (0xXX) bytes into 1 file... it will be big!), highly possibly poor compiler just coughs on them...
Well, I had this problem too. But in my situation putting all resources into .exe was necessary.
After this error I bought additional RAM (project is very important) and then my RAM became 12 GB (from 6 GB).
But I was very surprised when error hadn't disappeared :) After some googling, finally, I found answer there. The problem is cc1plus.exe executable memory limit. So, in case of Qt this problem can be solved in these steps (for Windows 7, MinGW32 4.9.2, for others probably simply needs to change paths):
If your OS is 32 bit, then in cmd (as Admin) put bcdedit /set IncreaseUserVa 3072
Install masm32;
Open cmd (as administrator too);
Put cd C:\Qt\Tools\mingw492_32\libexec\gcc\i686-w64-mingw32\4.9.2
Put C:\masm32\bin\editbin.exe /LARGEADDRESSAWARE cc1plus.exe
That's all.
Don't forget the obvious either: The message might actually be true and you really don't have enough memory, or the memory can't be made available for the process that needs it.
I've got 16GB of RAM on my system which ought to be plenty for my small application. "It can't possibly be that." I thought... but my machine hadn't been restarted in weeks.
A system restart is all it took to fix this error for me.
Trying to create something similar to SFX (self extract installer), I was including the setup files in one exe using custom resource in visual c++. When the size of the setup files reached over ~900 MB, the linker cannot generate an exe with the resources embedded. Strange thing is that the linker does generate an exe without any warnings. The exe generated is an statically linked MFC App (main app of the exectuable). However, non of the resource is included. I have watched the exe size during the linking from a console. It was showing 900 MB for awhile befored dropped to the 2MB exe in the end. If I removed some of the files (say total size will be 500MB), the exe is generated all OK with all the resources embedded. Is there a pratical size limit for the custom resource? Note that the final size of the executable is about 1GB which is way less that 2GB win32 app can address. So I am wondering is this a vc++ 2010 bug or feature? BTW, I also used /expectedoutputsize trick. But it does not help except the linking is much faster with a bigger expected output size.
Belated answer. Might be helpful to others. May be not an answer to your question, but this may be a solution to your problem. Check for 'Bitrock installer'. This also gives Self Extract Installer. I used it successfully in many of my projects for deployment.
According to the PECOFF Specification, the size of the Resource Data entries is 4 bytes ( IMAGE_RESOURCE_DATA_ENTRY.Size - see winnt.h )
The size, in bytes, of the resource data that is pointed to by the Data RVA field.
I've answered a similar answer here.
Basically append the binary + magic number (unique separator) to the end of the executable. At runtime open the executable for reading, find the offset via a magic number or another method and the rest of the file is your big data.
I have a QML Flickable with 3 QML image elements that cycle through 8 image files. My problem is that this uses a lot of memory on a Symbian device with very little. So when someone minimizes the app there isn't a lot of memory left for other apps. I want to know what function I can use on the focus lost event to release the cache. Otherwise Symbian closes my app when the phone runs out of memory.
I just ran into a very similar situation (literally). Apparently the QML cache is hardcoded deep inside the Qt source. I found a relevant posting at http://lists.qt.nokia.com/pipermail/qt-qml/2011-June/002743.html.
Unfortunately, a solution deriving from that link requires modifying your Qt build. I don't know if that's appropriate for your situation.
My current thinking is that the four constants defined at the top of src/declarative/util/qdeclarativepixmapcache.cpp file (lines 66-69, referenced from the above link) control when and why the QML image cache is modified. I'm setting the CACHE_EXPIRE_TIME constant to 0, as further logic inside that file indicates that with the constant set to 0, items in the cache expire immediately, and will therefore be removed. I'll update this answer as things develop.
Edit:
My proposed solution did work. In the QDeclarativePixmapCache.cpp file, change line 68 from
#define CACHE_EXPIRE_TIME 30
to
#define CACHE_EXPIRE_TIME 0
Rebuild Qt and your application, and images will not be cached (or at least, the behavior I'm seeing would indicate that images are no longer being cached). There are a couple of downsides to this solution:
Requires modification to Qt source tree
Unknown performance hit to the overall application - not an issue for me but something to consider.
This solution worked with Qt version 4.7. Good luck!
Have tried just setting the image element cache property to false ? Or maybe bind the image element cache property to somekind of focus/active property of your application ?