Loading UIImage into memory to avoid hanging when assigning to view
I have a scroll view setup with paging to show several blueprints that are a few mb each. I am trying to load the closest blueprints manually into memory while the user is about to interact with the scrollview. That way when I assign the image to the view to be rendered, the processing time is much quicker than loading from disk.
The problem is the images are loading into memory but aren't taking the same amount of memory as they should when applied. I assume this is because the render size is different? And I am still getting a hang when I assign the UIImageView.image to use my precached image as if it isn't using the memory. What am I doing wrong? I need to avoid any delays when assigning the image.
Here i am trying to cache the images by drawing them into memory and then storing the UIImage in an array to pull from later
let url = URL(fileURLWithPath: path + String(index) + ".png")
let imageData: Data = try! Data(contentsOf: url)
let image = UIImage(data: imageData, scale: UIScreen.main.scale)
self.loadedBuffer.append(image!)
Here is how I later assign the images to the 3 views, which causes a noticeable hiccup. This is the three views being assigned the 3 precached images.
for index in 0...loadedBuffer.count - 1
{
self.planImages[index].image = loadedBuffer[index]
}
EDITED: Tried to write a clearer description of what is happening and what I WANT to happen. Thanks for looking!
ios swift memory-management
add a comment |
I have a scroll view setup with paging to show several blueprints that are a few mb each. I am trying to load the closest blueprints manually into memory while the user is about to interact with the scrollview. That way when I assign the image to the view to be rendered, the processing time is much quicker than loading from disk.
The problem is the images are loading into memory but aren't taking the same amount of memory as they should when applied. I assume this is because the render size is different? And I am still getting a hang when I assign the UIImageView.image to use my precached image as if it isn't using the memory. What am I doing wrong? I need to avoid any delays when assigning the image.
Here i am trying to cache the images by drawing them into memory and then storing the UIImage in an array to pull from later
let url = URL(fileURLWithPath: path + String(index) + ".png")
let imageData: Data = try! Data(contentsOf: url)
let image = UIImage(data: imageData, scale: UIScreen.main.scale)
self.loadedBuffer.append(image!)
Here is how I later assign the images to the 3 views, which causes a noticeable hiccup. This is the three views being assigned the 3 precached images.
for index in 0...loadedBuffer.count - 1
{
self.planImages[index].image = loadedBuffer[index]
}
EDITED: Tried to write a clearer description of what is happening and what I WANT to happen. Thanks for looking!
ios swift memory-management
What are the pixel dimensions of these images, and what size are you displaying them?
– Duncan C
Nov 20 '18 at 23:40
CallingData(contentsOf: url)
is synchronous and will stall.. plus you are loading data twice.. First you are loading the image intoData
.. then you are loadingdata
intoUIImage
.. double the work.. It's slower than just callingUIImage(contentsOfFile: path + String(index) + ".png")
– Brandon
Nov 21 '18 at 1:16
I don't think it is loading the data twice. If I just assign UIImage using contentsOf: url nothing in my memory foot print changes, unless I am actually showing the image in a view. I am trying to load this into memory for use later, so I try to force the load by using the Data method.
– Dane Caro
Nov 21 '18 at 17:33
The problem is thatUIImage
keeps the uncompressed image data. It only gets decompressed once it needs to be displayed. This explains both the lag and why the memory size is smaller than expected. See this article on how to do the decompression in the background: cocoanetics.com/2011/10/avoiding-image-decompression-sickness
– Sven
Nov 21 '18 at 21:08
Thanks so much for that article Sven! That was what I was looking for in terms of understanding and logic. I just need to convert this over to swift and figure out how to decompress the image and store it for use. Thanks again!
– Dane Caro
Nov 22 '18 at 3:56
add a comment |
I have a scroll view setup with paging to show several blueprints that are a few mb each. I am trying to load the closest blueprints manually into memory while the user is about to interact with the scrollview. That way when I assign the image to the view to be rendered, the processing time is much quicker than loading from disk.
The problem is the images are loading into memory but aren't taking the same amount of memory as they should when applied. I assume this is because the render size is different? And I am still getting a hang when I assign the UIImageView.image to use my precached image as if it isn't using the memory. What am I doing wrong? I need to avoid any delays when assigning the image.
Here i am trying to cache the images by drawing them into memory and then storing the UIImage in an array to pull from later
let url = URL(fileURLWithPath: path + String(index) + ".png")
let imageData: Data = try! Data(contentsOf: url)
let image = UIImage(data: imageData, scale: UIScreen.main.scale)
self.loadedBuffer.append(image!)
Here is how I later assign the images to the 3 views, which causes a noticeable hiccup. This is the three views being assigned the 3 precached images.
for index in 0...loadedBuffer.count - 1
{
self.planImages[index].image = loadedBuffer[index]
}
EDITED: Tried to write a clearer description of what is happening and what I WANT to happen. Thanks for looking!
ios swift memory-management
I have a scroll view setup with paging to show several blueprints that are a few mb each. I am trying to load the closest blueprints manually into memory while the user is about to interact with the scrollview. That way when I assign the image to the view to be rendered, the processing time is much quicker than loading from disk.
The problem is the images are loading into memory but aren't taking the same amount of memory as they should when applied. I assume this is because the render size is different? And I am still getting a hang when I assign the UIImageView.image to use my precached image as if it isn't using the memory. What am I doing wrong? I need to avoid any delays when assigning the image.
Here i am trying to cache the images by drawing them into memory and then storing the UIImage in an array to pull from later
let url = URL(fileURLWithPath: path + String(index) + ".png")
let imageData: Data = try! Data(contentsOf: url)
let image = UIImage(data: imageData, scale: UIScreen.main.scale)
self.loadedBuffer.append(image!)
Here is how I later assign the images to the 3 views, which causes a noticeable hiccup. This is the three views being assigned the 3 precached images.
for index in 0...loadedBuffer.count - 1
{
self.planImages[index].image = loadedBuffer[index]
}
EDITED: Tried to write a clearer description of what is happening and what I WANT to happen. Thanks for looking!
ios swift memory-management
ios swift memory-management
edited Nov 21 '18 at 17:51
asked Nov 20 '18 at 23:01
Dane Caro
4516
4516
What are the pixel dimensions of these images, and what size are you displaying them?
– Duncan C
Nov 20 '18 at 23:40
CallingData(contentsOf: url)
is synchronous and will stall.. plus you are loading data twice.. First you are loading the image intoData
.. then you are loadingdata
intoUIImage
.. double the work.. It's slower than just callingUIImage(contentsOfFile: path + String(index) + ".png")
– Brandon
Nov 21 '18 at 1:16
I don't think it is loading the data twice. If I just assign UIImage using contentsOf: url nothing in my memory foot print changes, unless I am actually showing the image in a view. I am trying to load this into memory for use later, so I try to force the load by using the Data method.
– Dane Caro
Nov 21 '18 at 17:33
The problem is thatUIImage
keeps the uncompressed image data. It only gets decompressed once it needs to be displayed. This explains both the lag and why the memory size is smaller than expected. See this article on how to do the decompression in the background: cocoanetics.com/2011/10/avoiding-image-decompression-sickness
– Sven
Nov 21 '18 at 21:08
Thanks so much for that article Sven! That was what I was looking for in terms of understanding and logic. I just need to convert this over to swift and figure out how to decompress the image and store it for use. Thanks again!
– Dane Caro
Nov 22 '18 at 3:56
add a comment |
What are the pixel dimensions of these images, and what size are you displaying them?
– Duncan C
Nov 20 '18 at 23:40
CallingData(contentsOf: url)
is synchronous and will stall.. plus you are loading data twice.. First you are loading the image intoData
.. then you are loadingdata
intoUIImage
.. double the work.. It's slower than just callingUIImage(contentsOfFile: path + String(index) + ".png")
– Brandon
Nov 21 '18 at 1:16
I don't think it is loading the data twice. If I just assign UIImage using contentsOf: url nothing in my memory foot print changes, unless I am actually showing the image in a view. I am trying to load this into memory for use later, so I try to force the load by using the Data method.
– Dane Caro
Nov 21 '18 at 17:33
The problem is thatUIImage
keeps the uncompressed image data. It only gets decompressed once it needs to be displayed. This explains both the lag and why the memory size is smaller than expected. See this article on how to do the decompression in the background: cocoanetics.com/2011/10/avoiding-image-decompression-sickness
– Sven
Nov 21 '18 at 21:08
Thanks so much for that article Sven! That was what I was looking for in terms of understanding and logic. I just need to convert this over to swift and figure out how to decompress the image and store it for use. Thanks again!
– Dane Caro
Nov 22 '18 at 3:56
What are the pixel dimensions of these images, and what size are you displaying them?
– Duncan C
Nov 20 '18 at 23:40
What are the pixel dimensions of these images, and what size are you displaying them?
– Duncan C
Nov 20 '18 at 23:40
Calling
Data(contentsOf: url)
is synchronous and will stall.. plus you are loading data twice.. First you are loading the image into Data
.. then you are loading data
into UIImage
.. double the work.. It's slower than just calling UIImage(contentsOfFile: path + String(index) + ".png")
– Brandon
Nov 21 '18 at 1:16
Calling
Data(contentsOf: url)
is synchronous and will stall.. plus you are loading data twice.. First you are loading the image into Data
.. then you are loading data
into UIImage
.. double the work.. It's slower than just calling UIImage(contentsOfFile: path + String(index) + ".png")
– Brandon
Nov 21 '18 at 1:16
I don't think it is loading the data twice. If I just assign UIImage using contentsOf: url nothing in my memory foot print changes, unless I am actually showing the image in a view. I am trying to load this into memory for use later, so I try to force the load by using the Data method.
– Dane Caro
Nov 21 '18 at 17:33
I don't think it is loading the data twice. If I just assign UIImage using contentsOf: url nothing in my memory foot print changes, unless I am actually showing the image in a view. I am trying to load this into memory for use later, so I try to force the load by using the Data method.
– Dane Caro
Nov 21 '18 at 17:33
The problem is that
UIImage
keeps the uncompressed image data. It only gets decompressed once it needs to be displayed. This explains both the lag and why the memory size is smaller than expected. See this article on how to do the decompression in the background: cocoanetics.com/2011/10/avoiding-image-decompression-sickness– Sven
Nov 21 '18 at 21:08
The problem is that
UIImage
keeps the uncompressed image data. It only gets decompressed once it needs to be displayed. This explains both the lag and why the memory size is smaller than expected. See this article on how to do the decompression in the background: cocoanetics.com/2011/10/avoiding-image-decompression-sickness– Sven
Nov 21 '18 at 21:08
Thanks so much for that article Sven! That was what I was looking for in terms of understanding and logic. I just need to convert this over to swift and figure out how to decompress the image and store it for use. Thanks again!
– Dane Caro
Nov 22 '18 at 3:56
Thanks so much for that article Sven! That was what I was looking for in terms of understanding and logic. I just need to convert this over to swift and figure out how to decompress the image and store it for use. Thanks again!
– Dane Caro
Nov 22 '18 at 3:56
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53402903%2floading-uiimage-into-memory-to-avoid-hanging-when-assigning-to-view%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53402903%2floading-uiimage-into-memory-to-avoid-hanging-when-assigning-to-view%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What are the pixel dimensions of these images, and what size are you displaying them?
– Duncan C
Nov 20 '18 at 23:40
Calling
Data(contentsOf: url)
is synchronous and will stall.. plus you are loading data twice.. First you are loading the image intoData
.. then you are loadingdata
intoUIImage
.. double the work.. It's slower than just callingUIImage(contentsOfFile: path + String(index) + ".png")
– Brandon
Nov 21 '18 at 1:16
I don't think it is loading the data twice. If I just assign UIImage using contentsOf: url nothing in my memory foot print changes, unless I am actually showing the image in a view. I am trying to load this into memory for use later, so I try to force the load by using the Data method.
– Dane Caro
Nov 21 '18 at 17:33
The problem is that
UIImage
keeps the uncompressed image data. It only gets decompressed once it needs to be displayed. This explains both the lag and why the memory size is smaller than expected. See this article on how to do the decompression in the background: cocoanetics.com/2011/10/avoiding-image-decompression-sickness– Sven
Nov 21 '18 at 21:08
Thanks so much for that article Sven! That was what I was looking for in terms of understanding and logic. I just need to convert this over to swift and figure out how to decompress the image and store it for use. Thanks again!
– Dane Caro
Nov 22 '18 at 3:56