I've not watched the video yet, just flipped through the slides, but...
Is there any way to synchronize access with a collection that uses something other than a basic lock on an object?
We use ReaderWriterLocks on all of ours (as reads happen a lot but writes are pretty rare). At the moment we also have to maintain a read-only ObservableCollection that is modified on the UI thread whenever the underlying collection is changed (and the writer lock released). That's the one we give to WPF for binding.
How long until we start to see anything about what the content will be at PDC09?
We're doing pretty serious levels of desktop WPF development, but we're (generally speaking) not interested in Azure, mobile or the web (our software connects directly to some pretty serious hardware). I appreciate that that makes us an edge case, but I'll
need at least a general idea of whether there'll be any relevant content to make my case to management for a plane ticket from the UK!
We'd be interested in anything to do with desktop WPF, parallel programming (sonds like there'll be plenty of that) and general desktop .Net. The Rx framework looks awesome , BTW.
In case anyone else wants to know, Jaime Rodriguez mentions that DeepZoom didn't make it
Note: At PDC, we said that DeepZoom would be in WPF4. Unfortunately that feature has been cut. We just could not squeeze it into the schedule. There are workarounds to it: you can host Silverlight inWPF using web browser control or using the
Silverlight hosting APIs.
Has there been any decision yet on whether .Net 4 will include a WPF version of DeepZoom (i.e. MultiScaleImage, etc).
We've got an application that requires this functionality (with a custom tile source), and we're currently putting off implementing it ourselves until there's a decision, but all I keep hearing is "Maybe".
Take the Bitmap methods "GetPixel" and "SetPixel". Each call locks and unlocks some memory, which is an expensive operation.
Off topic, but I couldn't let it pass. In this particular case, that's not what's happening, IIUC.
GetPixel/SetPixel are GDI+ operations on the Bitmap object. They are handled by the unmanaged GDI+ code, which will (usually?) pass the operation off to your graphics driver. Your graphics driver is, of course, running in kernel mode, so user->kernel->user
context switches are required for each call!
This is the same when using GDI+ from unmanaged C++, and was also the case using old GDI as well. Get/SetPixel is horrifically slow.
Oh, and the lapsed listeners problem is an interesting one. Conceptually similar (to me) to circular references in COM.