Rob Relyea - XAMLified

# re: Silverlight use, power and deployment keeps growing; so does WPF@ Thursday, December 03, 2009 5:48 AM

Rob,

As you mention DeepZoom, I wonder if you could discuss what plans there are/aren't for a WPF version of DeepZoom?

I think it was you that once mentioned in a Q&A session (at Mix/PDC 08?) that although DeepZoom wouldn't make it into the next version of WPF, some work had been done, and there was some interest internally in releasing some sample code.

As it happens, I just posed this question to Lutz Gerhard, and he said that his team weren't working on anything in this area.

The bit I'm interested in is the tiling & rendering code (esp. the way new hi-res tiles are fetched asynchronously whilst doing a best attempt rendering of the lo-res tiles). We'd be wanting to implement our own tile source that rendered on request.

# re: Silverlight use, power and deployment keeps growing; so does WPF@ Thursday, December 03, 2009 6:57 AM

I think your link might have overloaded Pete Brown's server :P

# Dew Drop – December 3, 2009 | Alvin Ashcraft's Morning Dew@ Thursday, December 03, 2009 8:07 AM

Pingback from  Dew Drop – December 3, 2009 | Alvin Ashcraft's Morning Dew

# Daily tech links for .net and related technologies - December 3-4, 2009@ Thursday, December 03, 2009 10:54 AM

Daily tech links for .net and related technologies - December 3-4, 2009 Web Development Working With

# re: Silverlight use, power and deployment keeps growing; so does WPF@ Thursday, December 03, 2009 11:28 AM

Thanks for the comments, Rob.

In terms of our requirements (either for "DeepZoom" or something we write ourselves), we need to build an image viewer that can efficiently display images up to a resolution of about 8000x5000.

The interesting part for us is that we will likely be generating several color images by mapping RGB color palettes onto floating point grayscale images (@ up to 4000x3000) and displaying those side-by-side with a composite of those images (usually on top of a further 16-bit grayscale image at equal or higher resolution). We're trying to do this in real time whilst the images are being generated (line-by-line from an electron microscope).

What we'd like to do is build a system that can handle all of that with the minimum number of calls through the rendering & compositing code as possible as the user pans & zooms around! It would also be nice to do all the rendering on background threads so that the UI stayed responsive.

Obviously the "perfect" implementation of that could take a long, long time, but it looks to me like DeepZoom with a custom tile source would get us a long way there, if it were available. (We've been busy enough building the rest of our product so far to get around to doing anything too fancy, although we've got something that is fairly usable.)

AFAICT, hosting the Silverlight DeepZoom control would leave us having to implementing a local HTTP listener which mapped the requests to the right rendering code, so we'd obviously prefer a "proper" WPF version. We might even be happier with "sample" code than with a binary.

Cheers,

James

# re: Silverlight use, power and deployment keeps growing; so does WPF@ Thursday, December 03, 2009 1:05 PM

@rtpHarry

Sorry 'bout that. We had a local storm and power outage. Server was out for a few hours this morning.

Pete

# Silverlight use, power and deployment keeps growing; so does WPF … iSilverlight@ Thursday, December 03, 2009 4:18 PM

Pingback from  Silverlight use, power and deployment keeps growing; so does WPF … iSilverlight

# re: Silverlight use, power and deployment keeps growing; so does WPF@ Thursday, December 03, 2009 4:19 PM

My opinions:

"Should we build a general SilverlightHost element that would support DeepZoom and more?" -> As a temp solution, that would be ok.

"Should we build native WPF support for DeepZoom?" -> Absolutly

"What would the ideal implementation in WPF be?"  -> something that took full advantage of the local video card, DX??, threading, caching, and could be used as a tile client for the Bing Maps.  

BTW, IMO, The lack of a true Bing Mapping Control for WPF is a travesty.  

Thanks for the chance to voice an opinion.

Paul

# Silverlight use, power and deployment keeps growing; so does WPF … Silverlight Web@ Thursday, December 03, 2009 5:21 PM

Pingback from  Silverlight use, power and deployment keeps growing; so does WPF … Silverlight Web

# re: Silverlight use, power and deployment keeps growing; so does WPF@ Friday, December 04, 2009 9:35 AM

Hi Rob,

here's an interesting thing for you. Maybe this has to be fixed for SL4:

forums.silverlight.net/.../331165.aspx

# Enlaces Interesantes WPF/Silverlight 05-12-2009@ Sunday, December 06, 2009 5:15 AM

Llegan los del día   Silverlight Spy 3.0.0.6 (Koen Zwikstra) Have you checked out the new RichTextArea

# re: Silverlight use, power and deployment keeps growing; so does WPF@ Sunday, December 06, 2009 9:23 AM

@Rob

>> Voice your opinion

I have, many times, to the MS VE/Bing Reps to the company. They have heard me, just disagree with the need/timing.  They see their major market as the web, and I cant disagree with their findings.  But not having true tile client support for WPF in Bing Maps, shows us in the field, where priorities lie between WPF and Silverlight once more. You guys only have so many resources and you have to put them where the market says to.  For many things, right now that is Silverlight.  

Thanks for the ear

Paul