DataboundListbox Binding Outofmemory Exception with many images

[PraVEEN]

Hi,
I am using teleik RadDataboundListbox to display images in a page.I get an out of memory exception when I load more than 700 images(10-15kb each). I get image stream of each image from a http response. I use the image stream to set source of each BitmapImage item of the ObservableCollection I used to bind to the Listbox. I see that the application memory goes to 100 mb and then out of memory exception occurs.I assume the memory is running out as I am creating many BitmapImage objects to bind to the Listbox.

Is there a way to avoid the exception. Please Help.

[Deyan]

Hi Praveen,

Thanks for writing and for your interest in RadControls for Windows Phone.

You do not need to create an observable collection with BitmapImage instances in this scenario. You just need to have a collection with the URIs of the images (collection of strings for example) and provide them as a source of the list box. You then need to define an Item Template in the list box which will have an Image element in it having its Source property bound to the URI from the source collection.

All the best,
Deyan
the Telerik team

[PraVEEN]

Hi Deyan,

Thanks for the Reply.

I have tried binding Uri with out creating Bitmap objects. The memory usage is still increasing significantly(upto 90mb).
I guess this is because the Image data from the absolute URI is loaded to application memory while displaying them in UI.
Am I right?

Are there any other ways to solve this problem?

Thanks
Praveen Kumar.

[Deyan]

Hi Praveen,

Yes, when the resource identified by the URI is loaded it goes directly into the phone memory during its usage. Since visual items in DataBoundListBox are reused, you will not be saving all of your images into the memory and therefore now you no longer experience the OutOfMemory exception since you will be reusing the Image elements within your template.

This behavior cannot be changed.

My advice here would be to make sure that the images you are loading are not big since they will take a lot of memory when stored onto the phone. Make sure that you load thumbnails of the original images directly from the server since making the images smaller on the phone does not mean you are not loading the original image from the URI.

I hope this helps.

Kind regards,
Deyan
the Telerik team

[PraVEEN]

Hi Deyan,

I am loading only thumbnail images from the URI.
Did you mean DataVirtualisation by reusing visual Items?
If not can you please let me know if DataBoundListbox follows any pattern for reusing the visual items(like no. of items OR Memory restriction).

Thanks
Praveen Kumar.

[Deyan]

Hello Praveen,

DataBoundListBox implements a UI virtualization mechanism which creates a given amount of visual items (list box items) to fill the viewport of the control and reuses these visual items when you scroll to display the corresponding data items. In other words, visual items are not created for all items from our source but as many as it's needed to fill the viewport.

Can you please send us your project so that we can directly take a look at it and see how we can help you optimize the memory usage? You will have to open a new support ticket to send us your project.

Thanks for your time.

All the best,
Deyan
the Telerik team

[PraVEEN]

Hi Deyan,

I cannot Upload the whole project.Anyway I will try to make a sample project and uplaod it.
Thanks for the help. Your support is amazing.

Thanks & Regards.
Praveen Kumar.

[Deyan]

Hello Praveen,

Sample project is alright too. Thanks for the kind words as well.

We are looking forward to receiving your sample project.

We will consider this thread closed for now. Let us know in case you have further questions or need assistance.

All the best,
Deyan
the Telerik team

[Michael]

Hi Praveen/ Deyan,

Did this progress any further from the last post?

It would be interesting to understand if there were any issues seen in the sample solution that could aid me to improve my solution for a memory perspective. Please let me know if there was anything that was found and if there are things that I should look out for in my solution?

Many Thanks,

Mike

[Deyan]

Hi Michael,

Please refer to the other forum thread where you have posted your inquiry for further details.

Regards,
Deyan
Telerik

[Laurentiu]

Hi, I've read your replies and I have implemented a RadDataBoundListBox with ItemSource binding to a collection of image URIs. The images are not thumbnails so I have also added an URIToThumbnailConverter within the DataTemplate:

<Image Width="112" Height="112"
                       Source="{Binding Converter={StaticResource UriToThumbnailConverter}, Path=UriImage}"
                       Stretch="UniformToFill"
                       Margin="2, 0, 2, 0"/>

The problem is I still get an OutOfMemory exception if I scroll fast to the end of the list. I am thinking that the thumbnail creation within URIToThumbnailConverter take long time and during a fast scroll too many conversions will be started at the same time causing the out of memory problem.

One solution  would be to create thumbnails in advance, but this is not feasible for other reasons. So, my question is should I implement Virtualizing Data Collection and implement thumbnail creation on ItemsLoading event? Would this work? Is there any other option for RadDataBoundListBox  not to crash in the above context (option that maybe I have missed)?

Thank you,
Laurentiu

[Deyan]

Hello Laurentiu,

Thanks for writing.

Fact is that when your images are big enough you may easily go into invalid state. Even though they are JPEGs and represent several hundreds of kilobytes, when they are loaded and rendered in your app, they are treated as Bitmaps which, depending on the image size in pixels, makes from 10-14 megabytes, to 30-40. Therefore it is crucially important to use thumbnails in situations in which many images are going to be displayed on a single page.

If you send me your project in a new support ticket I will take a look and see if I can optimize your code but the above facts remain and should be considered.

Regards,
Deyan
Telerik