locked
Does VirtualSurfaceImageSource Make Sense in this Scenario?

    Question

  • I've been reading about VirtualSurfaceImageSource and it looks very interesting and useful in certain scenarios, but I'm trying to figure out whether it's the best choice for mine.

    My app does have an image viewer component where we want to let people pan and zoom bitmapped images much larger than the screen (for example, 300 dpi 8.5x11 PNGs or TIFFs). Right now, I use BitmapImage to create the bitmap source from the source file, and assign that to an Image. The Image is panned and zoomed entirely with transformations; we do not use ScrollViewer. 

    Performance is excellent, but it comes at a cost - very large memory consumption. The app can crash when more than roughly 10 large images are on the screen at once. So that's why I've looked into VirtualSurfaceImageSource, but there are still some things I'm not quite clear on, so here goes.

    (1) Regarding memory usage, it appears that when I currently load a BitmapImage with the source bitmap, the memory consumption increases by roughly the size of the bitmap, uncompressed, which is what I'd expect. If I used VirtualSurfaceImageSource, I don't see how this would change. I'd still need to load the entire bitmap into a 32-bit BGRA Direct2D surface in order to copy even the visible portions to the Direct2D device context, would I not? So it's not clear to me if this would solve my memory issue. 

    (2) Regarding efficiency, all the examples have the VirtualSurfaceImageSource sourcing an Image that is inside a ScrollViewer, and the VirtualSurfaceImageSource callback then receives correct information about what portions of the image need to be repainted based on the scrolling and zooming. However as I mentioned I don't use a ScrollViewer but rely entirely on transformations and clipping. Would the framework still be able to correctly inform my VirtualSurfaceImageSource callback of what portions are actually visible or not or would I be responsible for computing this entirely myself?

    Many thanks for any insights.

    Tuesday, December 30, 2014 3:29 PM

Answers

  • Hello,

    VirtualSurfaceImageSource is specifically designed for scenarios like yours. In these scenarios you might have very high resolution data that you want to allow the end user to pan and zoom. The key to successfully using this control is in preparing the image content. There are a number of ways you can do this but typically you would "chunk" the larger image into smaller segments. The smaller the segments the more memory efficient the control will be. You can also create multiple resolutions of the image so you can display the lower resolution image when zoomed out rather than loading the entire high resolution image into memory only to scale it down.

    I think your second question becomes moot if the control is used properly.

    I hope this helps,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Tuesday, December 30, 2014 9:24 PM
    Moderator

All replies

  • Hello,

    VirtualSurfaceImageSource is specifically designed for scenarios like yours. In these scenarios you might have very high resolution data that you want to allow the end user to pan and zoom. The key to successfully using this control is in preparing the image content. There are a number of ways you can do this but typically you would "chunk" the larger image into smaller segments. The smaller the segments the more memory efficient the control will be. You can also create multiple resolutions of the image so you can display the lower resolution image when zoomed out rather than loading the entire high resolution image into memory only to scale it down.

    I think your second question becomes moot if the control is used properly.

    I hope this helps,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Tuesday, December 30, 2014 9:24 PM
    Moderator
  • Hiya James -

    Appreciate the answer and sorry for not marking it sooner. Things got away from me.

    Quick follow up if you have a second - I think I understand your answer. Basically you're saying (which I guess is obvious) that because the image source is "virtualized" it's  up to me how I want to handle the virtualizing. I can tile, I can have different resolutions, I could render on the fly, whatever is most efficient for my application. Makes sense.

    Only thing I'm still unsure about was the second part of my question which you thought might be moot. Maybe it is, but every example I've seen of VirtualImageSource uses ScrollViewer. But I don't use ScrollViewer. So the question is will my callback still be notified correctly of what needs to be rendered if the image is manipulated using transformations and clipping as opposed to being inside a ScrollViewer?  My understanding was that the OS is the one who notifies my callback when and where painting needs to occur - that I'm not responsible for that. Maybe that's where I'm getting messed up. Assuming I'm not wrong, though, the question remains - will I get the proper notifications when the image goes off screen because of transformations and clipping?

    Thanks again,

    Peter

    Tuesday, January 13, 2015 5:18 PM