On my travels, I have recently been required to develop an application for a 10″ Android tablet. So we targeted the Toshiba Folio 100, thinking that as it has a ‘Market Place’ (all-be-it toshiba) you’d be able to develop and debug on the device its self.
Unfortunately not out the box! There are no drivers for the tablet at all, so the best you can do with the usb cable (not supplied) attached to your PC is use it as a mass storage device.
To enable eclipse to install development apps on the device, you need to follow these life saver steps: http://forums.computers.toshiba-europe.com/forums/message.jspa?messageID=217132.
Basically you need to edit the driver that comes with the SDK to include the name of this new device. Then I un-installed the driver that windows installed for it (Composite device) and re-attached the USB cable. This time I pointed it to my newly edited driver, and thankfully it worked! :)
Thanks a lot to the people on the Toshiba forums!
Monday, 8 November 2010
Monday, 23 August 2010
Silverlight Animation Memory Leak in FillBehaviour
My first post of significance! Yay!
After months, *litrally* months of debugging, heap walking and cursing, with the help of the kind people at Microsoft and the Silverlight team, I’ve found the root cause of my memory leak.
The situation was, that I was using an ItemsControl with DataTemplate, whose contents animated independently.
To create the animation, I didn’t declare the fill behaviour of the storyboard, and consequently it defaulted to HoldEnd, which of course kept the last value of the storyboard. All well and good, and this was the desired behaviour.
Turns out though, that the animation I was using, is only properly cleared up from using two of the following:
Great! So hold end doesn’t clean up resources.
The solution is to drop the hold end usage and somehow work in Stop somewhere. After that your memory leak should be significantly less!
Again, not sure about the mechanics as its a bug in the Silverlight libraries, but from my testing, switching fill behaviours certainly works! :)
I’ll try and embellish this post soon with more information, but I’m currently still trying to understand the full implications myself!
Hope this helps someone!
After months, *litrally* months of debugging, heap walking and cursing, with the help of the kind people at Microsoft and the Silverlight team, I’ve found the root cause of my memory leak.
The situation was, that I was using an ItemsControl with DataTemplate, whose contents animated independently.
To create the animation, I didn’t declare the fill behaviour of the storyboard, and consequently it defaulted to HoldEnd, which of course kept the last value of the storyboard. All well and good, and this was the desired behaviour.
Turns out though, that the animation I was using, is only properly cleared up from using two of the following:
- Using FillBehaviour=”Stop” in xaml
- Using Storyboard.Stop() in code
Great! So hold end doesn’t clean up resources.
The solution is to drop the hold end usage and somehow work in Stop somewhere. After that your memory leak should be significantly less!
Again, not sure about the mechanics as its a bug in the Silverlight libraries, but from my testing, switching fill behaviours certainly works! :)
I’ll try and embellish this post soon with more information, but I’m currently still trying to understand the full implications myself!
Hope this helps someone!
Subscribe to:
Posts (Atom)