Loading UIImage into memory to avoid hanging when assigning to view












0














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!










share|improve this question
























  • What are the pixel dimensions of these images, and what size are you displaying them?
    – Duncan C
    Nov 20 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 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 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 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 at 3:56
















0














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!










share|improve this question
























  • What are the pixel dimensions of these images, and what size are you displaying them?
    – Duncan C
    Nov 20 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 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 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 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 at 3:56














0












0








0







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!










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 21 at 17:51

























asked Nov 20 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 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 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 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 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 at 3:56


















  • What are the pixel dimensions of these images, and what size are you displaying them?
    – Duncan C
    Nov 20 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 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 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 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 at 3:56
















What are the pixel dimensions of these images, and what size are you displaying them?
– Duncan C
Nov 20 at 23:40




What are the pixel dimensions of these images, and what size are you displaying them?
– Duncan C
Nov 20 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 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 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 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 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 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 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 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 at 3:56

















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
});


}
});














draft saved

draft discarded


















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






























active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Wiesbaden

Marschland

Dieringhausen