How can I create an animated tile on WP7 similar to the XBox Live Tile? What are the options for Animating tiles in general?
After a good bit of research I leaning towards it is not possible. You can use push notification to update the tile which does add some flexibility and opportunity but achieving the same effect as the XBox live tile is looking unlikely. With that said I do understand the motivation for the limitation if animations were available this feature would be abused and would ultimately lead to slow devices.
In a recent Channel 9 video (about 11 minutes in) the softie presenters say this requires Microsoft "special sauce", e.g. this feature is not available to non Microsoft developers. I am guessing (only a guess!) that they will eventually open this feature. The link is here: http://channel9.msdn.com/Shows/This+Week+On+Channel+9/TWC9-mvcConf-WP7-Tools-update-AsmSpy-JavaScript-OO
Related
I was talking to another developer recently and we started to discuss Window Phone 7 development. Their thoughts, from what they had heard (i.e no hands on knowledge) was it was really just Silverlight development. My reaction was that I see a lot of posts these days regarding Silverlight that call out being for "Windows Phone 7" so there must be some distinctions between the two.
So what I'm wondering is what are the differences between developing for WP7 v. the browser plugin.
The things I can think of, but seem obvious are:
WP7 Silverlight version isn't the same SL 4.0 but more like SL 3.5+
the hardware is different (memory\cpu)
I assume there are some different controls
you need to take into account the form factor
Not discounting the above list, which are important, but what else is different when developing a Silverlight application for WP7 v. browser plugin?
Thanks
There are a lot of technical differences and sure there are plenty here who give you bullet list of these. However there are really just a few real differences that make a big difference to how you develop apps for WP7.
Its a touch interface people
Quite a few apps I've played with from the market place seem to have developers struggling to grasp the concept of a touch based interface. Its clear that many are still using the left mouse down event when they ought to be looking for a "Tap" gesture. This can be frustrating for users trying to "flick" and find they've "clicked" instead.
So make sure you are using a gesture based framework (toolkit has one) so you don't annoy the users.
Your app will tombstone
WP7 guards its resources jealously. At a moments notice your app may be deactivate as the search screen or start screen is invoked. Volatile state of your app will be lost. WP7 API includes a number of ways of keeping key small chunks of data when your app gets "tombstoned" so that when the user returns to it, it should be able to restore near enough the same state it had before. However this isn't done auto-magically you have to code for it.
Again some of the apps in the market place don't handle this well and when you have an Omnia 7 which has a seriously sensitive search button that can be really frustrating.
Network access and other services are intermittent
If you are developing a connected app you need to cope gracefully with changing network access or loss of access all together.
Read the manual
Whilst there are plenty of resources get devs up and running real quick the devil is always in the detail. I recommend you at least start with reading Fundamental Concepts for Windows Phone which will cover some of these issues.
TBH there are a lot. Some of them:
Touch input vs Mouse clicks
Sounds and music
Silverlight 4.0 "/content/song.wma"
Silverlight for Windows Phone 7 "content/song.wav" (mind the slash)
Navigation philosophy
WP7 SL has two threads by default. One (compositor thread) runs all animation, second (UI Thread) runs the rest.
Controls have very diffrent default behavior and look
and many other OS realated
Better than any explanation, you should refer to the official website.
Silverlight for WP has support for (according to the same doc):
Hardware acceleration for video and graphics
Accelerometer for motion sensing
Multi-touch
Camera and microphone
Location awareness
Push notifications
Native phone functionality
It doesn't have regular COM bindings and it has somewhat limited access to reflection, among all restrictions.
For a complete list of features supported in Silverlight for Windows Phone, read this document.
I’m working on creating a full-screen 3-D app (based on Johnny Lee's Wii head tracking app) with some augmented reality features, and it seems that WPF is too slow to render even the simple models I’m using at a reasonable frame rate. I think the problem is that I need to change both the view and projection of the camera on just about every frame, because of the nature of the app (it uses a web cam to track your face, and uses that data to move the camera around and change its perspective).
I've spent a lot of time trying to narrow down the problem, and it's definitely related to the graphics, and not the speed of the head-tracking API that I'm using. Also, I recreated the app in XNA, and it seems to work fine there (28 FPS versus 9 in WPF). Finally, when I remove the "walls" or make the window much smaller (say, 800 x 600), WPF's performance greatly improves, which makes me think that the bottleneck is the graphics calculations.
As a result, I need to either find a new graphics back-end to work with, or find a way to make WPF much faster for this app. I’m mostly looking at DirectX and XNA, and possibly OpenGL. Any recommendations on which of these APIs would be best to use for this app in .NET? Or alternatively, any idea what I'm doing wrong in WPF that's slowing things down?
I've not done enough with 3D in WPF to be able to say what could be causing the slowness, but I did notice that it's model datastructure isn't very efficient. While this might not be the cause it could be symptomatic of general slowness to the whole pipeline.
One thing that does spring to mind is that WPF is rendering the scene in software rather than using the hardware acceleration on the graphics card. The fact that you get better performance (though you don't say how much better) with a smaller window.
If you remove any textures from your model do you get better performance too?
I don't think it really matters whether you go for Direct3D or OpenGL - virtually all modern cards support them equally well. XNA is the obvious choice if you're sticking with .NET as it's integrated into Visual Studio - even the Express edition.
I would check out SlimDX, a much thinner DirectX wrapper than XNA or WPF
The problem with changing the projection on every frame is that API's like XNA/WPF werent designed with this in mind, so were optimized to have projection set once in the initialization phase, then not again.
I would suggest a hybrid choice here: use WPF for what its good at (Windows UI, composition, etc) and use XNA to render the 3D. There are samples out there that demonstrates combining XNA with WinForms. It should be possible to do the same "trick" to render XNA onto surfaces in WPF.
Update: there are supposedly issues with using XNA directly with WPF. This thread indicates that using XNA with WinForms and then hosting the WinForms control in WPF is a workaround to these issues. I've not tested this myself though (yet).
Are there any controls that anyone is aware of that I can use to stream firewire video into a WPF app. I do not need camera control or capture just the video. I need WPF hosting because I'll be adding WPF content on top.
I was hoping that with the addition of having direct X surfaces in WPF something like this might appear.
Ideally looking for something relatively high level (not a direct show guy at all).
Thanks,
Brian
There are a couple really good video rendering packages for WPF. This guy Jeremiah Morrill has a blog where he discusses his numerous render projects. There's the WPF Win32 render project, and a number of low-level techniques he documents for how to access accelerated playback, Media Foundation .NET, DVD controls, etc... I believe his blog is titled "Jer's One Stop Shop".
Reading over his blog in general is a good idea if you are in to video/WPF. Last I checked, "MediaKit", one of his more comprehensive projects, enables easy use of DirectShow (simple xaml and your off and running, so don't worry) and other well known native interfaces. It's very robust and actively maintained, if not that specific project, check into some of the recent API's he's contributing on, some various Win7 media support also.
The only reason I'd bring up this other project, Augmented Reality, is that you remarked about adding content "on top". You should definitely check out wpfAugRel if your doing a lot of video production. Where to get an add on for it eludes me, but I'm sure you can find it off that site, but it allows for you to script in python some fairly slick real-time video production.
-- edit --
Right, look at this google code page, it has some video's (picture's worth a thousand words right?), but regardless, it allow's you to mix in 3D content into live-action, through the use of "marker" prop's, essentially bit's of paper with some easily machine recognizable feature's, that facilitate their underlying engine to inject computer rendered output into a real world scene, highly dynamic, so you can toss these marker's around and the 3D content move's fluidly... anyhow good luck.
Check out this article by UberDemo. It captures video into a WMV file with Windows Media Encoder and WPF. There is a paragraph about how to do the preview in a WPF application.
Is it possible to access a webcam in Silverlight
From what I've read it's not possible in Silverlight 1.0 but what about 2.0... 3.0 ... 4.0?
It is now possible in Silverlight 4.0. Developer preview is available at http://silverlight.net/getstarted/silverlight-4-beta/
I'm afraid webcam support isn't available in Silverlight 2.0. You might hope for it to be added in a future version, but there's no easy way of doing it now... Saying this, some people have invented various hacks that use other technologies in combination with Silverlight to capture video from the webcam. They typically involve interfacing with Flash, which of course is perfectly capable of utilising webcams. See this article for an example (with source code included). It's not a pretty solution (at least in my opinion), and may not be 100% stable across browsers/platforms, but I think it's the best you're going to get for now. Perhaps you should submit feedback directly to Microsoft if you really want to see support in Silverlight 3.0 (though it's certainly been mentioned elsewhere, so it may already be on the to-do list).
Silverlight 4 supports web cams. To capture images you can use www.glo6.com/camera1.aspx
It saves encoded images to web server. If there is a need to motion tracking, save images regularly, and then compare them on your server with another application.
I asked a member of the Silverlight team when they would be coming out with webcam support, and he said, in effect, "Let's just say that it's a really high priority for Silverlight 4.0." That said, it hasn't been officially announced yet, so I wouldn't count on it until MS does make the announcement.
I've used the Silverlight -> JavaScript -> Flash hack in production code, and while it does work, it doesn't work very well. Among other things, it's a pain to keep the Flash camera synchronized with your Silverlight UI. The camera shows up on top of SL child window controls, for instance, and of course, doesn't obey the clipping rules for when, say, it should be scrolling out of sight in a list box. And animations are a PITA as well. It's all possible, just slow and unpleasant, and several orders of magnitude more work than it would be if MS just supported web cams in Silverlight.
My company is just starting to look at using WPF for migrating all of our 10 year old business applications. These applications will most of the time be running on computers that have limited/old hardware. We are now a little worried that the hardware might be too limited for using WPF.
We have installed Family.Show (http://www.vertigo.com/familyshow.aspx) on an basic older computer and that seems to run ok. But we would like know what your experiences with WPF on older hardware is? Anyone out there willing to share some experiences with us?
I would add several things:
The first is, as Stu said, it really depends on what you are doing. In particular, we have found a noticeable difference between WPF 2D and WPF 3D. If you are doing any WPF 3D stuff at all, your performance is highly dependent on the quality of the video card (see the Graphic Rendering Tiers link already mentioned). In particular, we released a WPF 3D feature in April of this year, and it really only worked smoothly on Tier 2 hardware.
Second, I would point you to Jossef Goldberg's blog. It has a wealth of information on WPF performance related items.
Third, I would grab and utilize the WPFPerf tools. They were recently updated actually. Jossef's blog post will point you in the right direction there as well.
Fourth, take advantage of virtualization wherever you can.
Finally, I would recommend monitoring performance all the way through the development life cycle. I think the story goes that originally the Blend team did not evaluate performance (for their first release) till closer to the end, and it made solving the problem much more difficult.
Update: There is another StackOverflow post on this subject. Just wanted to point others to it.
WPF apps will generally run no slower than their equivalents using other technologies. In other words, performance depends on what you're doing. If you have a basic app with some simple data entry controls and a grid or two then it'll be a lot less demanding than an app that has animated custom controls with overlaid video, etc.
You should also bear in mind that you must have at least XP SP2 to install WPF, which sets a reasonable hardware baseline anyway.
In summary you should have no problems running a WPF app on older hardware as long as you are sensible with the frills. Given WPF's templated controls it's also fairly trivial to test for a basic level of client performance at runtime (see Graphics Rendering Tiers) and only enable more advanced features on suitable hardware.