[Q] ListView Scrolling Buffer Modification - Droid Incredible Q&A, Help & Troubleshooting

I'm wondering if it's possible to modify the "buffer" between when touch input is detected on a list, and when the list actually begins to move when you scroll. Some discussion from back in December of last year on Romain Guy's blog can be found here: http://www.curious-creature.org/2010/12/02/android-graphics-animations-and-tips-tricks/
A few of the relevant comments:
Kleptine says:
December 4, 2010 at 1:19 pm
@Jay/Kristoffer
It seems to me that one of the more blatant scrolling inefficiencies is the fact that it take a couple hundred milliseconds to detect the scroll action after pressing the ListView. It’s fairly apparent on my Nexus One.
to which Romain Guy responds:
Romain Guy says:
December 5, 2010 at 12:49 am
@Kleptine: this was of course tested with users, and the threshold value was chosen based on the “noise” introduced by simply touching the screen.
The meaning of Romain Guy's comment about the "noise" introduced is unclear to me, but I'm wondering if it's possible to reduce the amount of the buffer for a more immediate response to scrolling on our Incredibles, whether through a pre-compilation modification of the code or even once we've got a ROM up and running.

Perhaps the 'noise' is simply the time at which point your finger makes contact with the glass?
¦*¦HYBRID¦*¦SPEED¦*¦ by ws83

Well, to my best recollection, noise in a photograph is unwanted fuzz/haze. Might mean the same here, meaning that the threshold chosen is to weed out any unwanted/accidental touch input.
Don't take my word for it, been wrong before. Lol.
Sent from my Hybrid using XDA Premium App

Right, but I'd like to know if we can experiment with reducing that buffer and seeing how it effects overall performance--WP7 and iOS track finger motion noticeably closer on the screen without causing unwanted touch input. Whether that's due to something else in the code, like precautionary measures that allow for this higher sensitivity without causing other issues, I'm not sure.

Related

[APP][ALPHA] G Force Logger for Vehicle Performance (no, not gPC)

Hi, my name is Eric. I've been working with WinCE for a long time (since WinCE 2.0 haha) and I've regained interest in PPC programming. Working with few things here and there, mostly experimenting.
In anycase, I've got an idea to record g forces on a vehicle while it's being tested to its limits (AutoX, drag race).
Now, I know there's already a piece of software out there, gPC, but it isn't completely refined (indepth calibration, angle corrections) or completely free (by donation).
The goal of the project is to create something similar to a device called gTech which goes upwards of $300 for the basic model.
Key features will include:
- a reset function + algorithms to compensate for device orientation
- graphs of resulting logged data
- logging of calibrated data and raw data
- Driving aids
- Flashing screen to indicate reaching of new peak G (separate indicators for forward and lateral)
- a screen showing realtime overlapping graphed data for all axis
- a 2d grid with a cursor indicating current forward and lateral g
- on the same 2d graph, a drawn boundary indicating limits of g achieved (this will eventually look like an egg after working the car hard)
- and finally, real time telemetry transmission via edge/3g to a receiving computer
The ultimate goal of this project is to provide reliable data for motor enthusiasts whether they would like to see if their shifting is smooth, or if they're braking, or powering on in the right places or if their car mods have had any effect (this last one is pretty useful to quantify). In addition, provide some rudimentary tools to assist in competitions and spirited driving in the form of g limit warnings (flashing screen, large indicators of current g). In the case of spirited driving on a mountain road, the device can warn when approaching loss of traction (after collecting limit data) to prevent going off a cliff.
Venues of use:
Auto Cross
Track Days
Drag Strip
Skidpad
Of course, I have to insert here, that this device can't save your bacon if you do something idiotic and by no means do I condone dangerous driving.
With that said, all the above is what I hope to achieve and any of your comments is well appreciated.
Current Release:
v0.1
Alpha stage, rudimentary raw data output via numbers and a line (indicating X and Y recorded g) and a circle (indicating Z g). The numbers shown are the raw numbers recorded from the accelerometer and not converted to m/s^2. Although, you can probably do that math on your own if you're smart enough (simple scaling). What I've discovered is that each accelerometer is different, and even going from a negative axis (eg, device upside down) to positive axis (device right side up) will give different numbers. In addition, if you run the program, you'll notice a lot of jitteriness. I hope it doesn't affect the accuracy once I smooth them out with a segmented average.
Executable is packaged in a zip. It contains an EXE which can be straight run with Dot NET CF v2.0 (basically, all WM 6.1 devices)
Hi Canagan,
Great idea, I will certainly be testing this out.
I would like to ask, would it be possible to be able to include 1/4 mile time, and 0-60 etc so we can work out HP of the car. There is a similar app for the Iphone called Dynolicious http://gizmodo.com/5030749/iphone-apps-we-like-dynolicious-car-performance-meter
Thanks.
Whoooaaa sound a really good app ! Will test it this weekend ! Thanks
PooleyUK said:
I would like to ask, would it be possible to be able to include 1/4 mile time, and 0-60 etc so we can work out HP of the car. There is a similar app for the Iphone called Dynolicious http://gizmodo.com/5030749/iphone-apps-we-like-dynolicious-car-performance-meter
Click to expand...
Click to collapse
Yes, I can do that if there's more of a demand for it. Calculating horsepower is fairly simple, however, I may put 1/4 mile times and 0-60 towards the end of development as they require tieing into the GPS.
Great idea.. I will test it also
It seemt to be working on my Touch HD. But are the meaning of all these numbers??
CanaganD said:
Yes, I can do that if there's more of a demand for it. Calculating horsepower is fairly simple, however, I may put 1/4 mile times and 0-60 towards the end of development as they require tieing into the GPS.
Click to expand...
Click to collapse
Cool, looking forward to seeing this develop.
So far the accelerator test seems to be working fine.
would be need ive i could see how many hp mycar has

Transparent controls in native WM apps

Hey all,
I've been searching for techniques people use to make transparent controls. The problem with windows mobile is that windows always have the CLIPCHILDREN window style set. So you can't grab the contents of the parent window (in WM_ERASEBKGND for example) because it isn't there.
One technique would be to have the parent pass the handle of the background DC it uses to the child control but that involves having a memory DC around all the time. And if the child control is covering any sibling controls you'd be out of luck as well.
Another solution I've read about is to temporarily hide the child window so the parent window is forced to redraw the parts that would normally be obscured by the control. I personally do not like this approach. (the drawbacks are also discussed on some MS forum, i'm not allowed to post outside links yet, google for "Rounded Buttons : Does any one see any problems with this method" and you will find it)
So, there are ways to achieve what I'm looking for but they are far from optimal. Just wondering what everybody else is doing to achieve this.
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Chainfire said:
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Click to expand...
Click to collapse
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
PegNosePete said:
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
Click to expand...
Click to collapse
Well the method I use in my own new UI's is indeed per form (excluding WinAPI controls like edit boxes and such) draw using only one DC.
The problem is that any 'windowed' control, the parent will not draw to the DC if a 'windowed' control overlaps. Due to CLIPCHILDREN all data drawn to that position is simply lost.
Now, handling WM_PAINT you can get the entire update region, which tells you which parts of your form have to be redrawn. You must use this information, because blitting the entire form is very slow!
In essence, to do this right you well end up faking most of the GDI system, including your own 'fake' child windows, invalidating and revalidating portions, calculating the intersections of your 'fake' invalidated regions of the screen with the update region you get in WM_PAINT and redrawing those parts.
There are several different strategies to go about this, one is to redraw on demand, another one is to use double buffering.
I personally mostly use the double buffering technique, as this easily provides every 'fake' control with a bitmap of it's own region. A child control can then alphablend using the parent's buffer as one of the alphablend sources.
You can of course combine this with keeping state information whether a child, grandchild, etc is using alpha / transparency and this with an algorithm deciding which control needs double buffering or can draw on-demand, which can give both speed and memory use advantages. In a lot of situations you can then suffice with only double buffering the 'top' component (form) and a select number of child components.
Of course two drawbacks of per-control double buffering are speed and memory use. You can eliminate the complete-form double buffer with some smart coding and calculating. This will give you a slight speed and memory advantage. Memory use is high because many of your controls will have a copy of their current state.
This can be as complicated, feature-filled, fast and efficient as you are willing to make it. The better you can design the code the better it will work, but it is not a trivial task. There are many ways to go at this, no one way is definitely better than the other ways. It depends on what your applications does with it's display, how simple you are drawing (are you making a simple white background, or a background based on images for example gradient?), which method is more efficient.
The other method is getting the update region and actually perform redrawing of those invalidated sections (instead of copying from buffer). I can tell you from experience that if you are using image backgrounds and alphablend calls, this will be _much_ slower than double buffering (if done right).
I know all of this probaby makes little sense, I'm not a hero with explaining things ... you really have to figure this out for yourself, I guess.
Other advantages of building your own UI system are that if you do it smartly and buffering, it is very easy to port to directdraw, and possibly even GL. But I must warn you, on far the most devices actually using directdraw for this stuff is not much faster, it is in fact hardly noticable. If you manage to make a GL port, that can especially on older HTC devices (pre-HD2) be much faster.

[App] Simple Audio Analyzer (WIP)

This is something I started dabbling on while trying out various SDK things, but continued developing on after first tests. Still work in progress, but it works good enough.
It's a simple application that captures from the phone's microphone and presents the recorded data either as FFT graph, waveform or displays it as SPL/peak/RMS volume meter with graphical history function.
I've put already an earlier show-off on Youtube, but I was on a coding roll, this is a newer (unlisted) demo. Irregularities in the displays are caused by a confirmed bug in XNA.
http://www.youtube.com/watch?v=F7M6qUU3fuM
(Uploaded it a few minutes before this post, video quality will improve.)
Looks cool! Will it work in landscape also?
Hey Tom. You made some good points on Anton D. Nagy's blog, but I reckon it could be optimised. Right now it's very pretty, to attract buyers (e.g. me!) you'll need to provide something really useful. This could include things like highlighting clipped samples, recording to isolated storage or even integration with the Zune hub.
How many frequency bands are you managing with the FFT? For the purpose of a phone you could keep it to 128 or even 64 and save processing power. You're right about needing a dev device to really know.
Good luck, I really like what you've done so far.
I could swear I had already written up something and it seems gone.
Anyway, the app's going to be free, so no need to entice buyers, since there won't be any.
Also, the main intent of the application is to capture ambient sounds/noises and get a visual representation. And since I want to keep it as simple as possible, I'm probably going to leave it at that.
Your comments however gave me the idea to write a simple recorder, that does an audio display with zoom and cursor on both waveform and FFT representations. I don't think applications will be able to directly open something outside their isolated storage, so loading music from your phone will probably not be possible, apart from making a media player proxy play back stuff.
Looks great..very impressive.
I'm tinkering with the same API although I'm a real novice and wondered how you were managing to get at the data being picked up by the microphone in apparent real-time.
I wonder if you would be good enough to let me into some of your coding techniques or point me at some good reference docs/samples I've obviously missed
The code samples I've seen up to now have start record and stop record buttons, with a buffer being filled up over that time period and finally played at the end.
I'd like to do how you managed to process and graph the data as it is picked up by the mic. Are you possibly setting the buffer size very small and just getting small chunks of data and then acting on it - accepting the potential delay in buffering and then processing - maybe the delay is smaller than I'm expecting? or is there some other technique I'm missing from the docs.
Thanks in advance.
Ian
The recording code works practically the same as you'll find in the samples. Signal processing happens on the BufferReady event, which calls respective processing functions. I've set the buffer size to 100ms, which is the minimum XNA allows.
DMAND said:
Looks cool! Will it work in landscape also?
Click to expand...
Click to collapse
Now it will.
http://www.youtube.com/watch?v=k3fLPgJX7g0
Very nice!! I love how it just fits in perfectly with the Metro UI
Hi Tom,
How are you analyzing the audio stream coming off the microphone? I'm trying to do something similar to match sounds with known pitches/frequencies (similar to using the MediaPlayer.GetVisualizationData method) but not sure if I'm missing a simple way of doing it, or if you are analyzing the raw bytes from the stream.
Thanks,
Dave.
I'm capturing raw data directly from the XNA Microphone class and then running it through a FFT routine. I'm using Exocortex DSP, which I've stripped down to the bare minimum.
Hi Servo!
I was wondering how you were able to code the audio to be represented visually in silverlight. I'm looking to do a similar kind of app showing a VU-meter that responds to the audio. It'd be 16 distinct blocks vertically that, based on the incoming audio, light up according to audio strength. I can find samples of accepting microphone input, but how do you turn that visual?
Thanks!
Hi tom, very nice work and excactly what I can use.
Have to do some simple sound measurements every now and again.
Nothing exact but enough to give me an idea what I'm dealing with. This app would be perfect for it. Can't wait to try it.
Hi tom, I bought your 2,0 version of this and I really like where it is going. I need something like this for tinkering with audio setups.
On your graph, could you post some graph lines with maybe some labels (.5 1k 2k...) so I can see where certain peaks lie? it could be toggle-able in the settings?
Also, any plans for some auto or manual calibration?
Its a shame the API only lets you work up to 8k, I wonder why?
Keep up the great work!
i bought this too, and really like it!
But, how accurate is the dB meter??...

Are third party apps really slow?

Has anyone with an official device tested the speed of third party apps yet? Is it really as slow as engadget claims them to be? I know there will be slow apps and malfunctioning apps, but what about the majority of apps? Do they load/run fast enough?
Are there atleast 20 games/software that look great,run fast and function well? I rather there be 100 quality apps than 20000 rubbish apps.
If applications try to do more than the CPU can do, they'll be slow. Any excessive slowness is due to bad programming.
The only bad thing here is that there aren't any math/multimedia intrinsics in Silverlight for WP7 optimized for the ARMs VFP and DSP.
Considering M$ should be testing all the applications that come though to the marketplace... Most of them should load pretty quickly.
Unfortunately, i can partly confirm that.
While application load times are clearly a developer fault (while Seesmic is slow as hell the official Twitter app developed by Identity Mine is very fast in starting and downloading tweets), there is a huge problem with the listbox scrolling performance.
Some apps also fail in sidescrolling but these are mostly apps that make heavy use of graphics so ... their fault.
But Listbox is an issue and listboxes are something that nearly every app uses. I also develop a feed reader and I am not able to reach a performance that is on par with the scolling behaviour of the native apps. Not nearly on par. I got it working better than most of the available apps as most of them ignore Microsofts guidelines for a good listbox performance (they do not use listbox items all of the same, fixed height, for example) but no matter what I do and how simple my datatemplate is, its jaggy, jaggy, jaggy.
If you spend a lot of time optimizing your item/data templates, it will be good enough for now until Microsoft hopefully come up with a fix for these problems. But I think (and I can see on the available apps) that most devs don't spent this time and most of the apps currently available really are jaggy as hell. This is going to be a huge problem for MS in the months to come, bad press will pop up for sure everywhere because of this issues.
If the border is so clear between 1st party and 3rd party apps, it is really a problem.
(I use a HTC Trophy device)
I'm not sure how much trouble it is to implement it, but what you can do is fill in the listbox item data/template when they're about to become visible, and remove it when it goes out of sight. Since the whole listbox item stack height is deterministic if every item is the same height, it should be easy to do and calculate when something is about to become visible (I guess the hardest part would be accounting for inertial scrolling). Anything that's not visible would be an empty listbox item with specific height.
The actual problem's probably the rendering graph becoming terribly huge when every listbox item has a content (either directly or via item template), bogging the render thread down doing its visibility culling.
I guess it doesn't help that the first party applications use UIX instead of Silverlight.
Deferred loading with a listbox
http://blogs.msdn.com/b/delay/archive/2010/09/08/never-do-today-what-you-can-put-off-till-tomorrow-deferredloadlistbox-and-stackpanel-help-windows-phone-7-lists-scroll-smoothly-and-consistently.aspx

WP7 Small Touches?

What are some small aspects of WP7 that you appreciate that others may not have noticed?
For me, after about two or three weeks of having the phone, I realized something about the text message tile. This is most likely old, but, if you have no messages, the smiley will be like this , if you have a message - ;-), if a message failed to send - :-( (or something like that, I don't quite remember it), if you have 4 or more messages - :-O
It was just something that made me smile and think, "really? who would have thought of including that?"
Anyone else have moments like this?
loopyeyes said:
What are some small aspects of WP7 that you appreciate that others may not have noticed?
For me, after about two or three weeks of having the phone, I realized something about the text message tile. This is most likely old, but, if you have no messages, the smiley will be like this , if you have a message - ;-), if a message failed to send - :-( (or something like that, I don't quite remember it), if you have 4 or more messages - :-O
It was just something that made me smile and think, "really? who would have thought of including that?"
Anyone else have moments like this?
Click to expand...
Click to collapse
Really, that happens? That's a really nice touch!
For some reason I always loved how the arrow button rotates around when switching between the Live Tile view and the Apps list view. I don't really know why I like it, but I just do!
OGCF said:
Really, that happens? That's a really nice touch!
For some reason I always loved how the arrow button rotates around when switching between the Live Tile view and the Apps list view. I don't really know why I like it, but I just do!
Click to expand...
Click to collapse
Yes that really happens, it is touches like this that make the device a delight to use, I really like the on screen keyboard, it feels just right in use
It turns out, every time you type on the soft-keyboard in WP7, it’s a subtly different sound. Whereas the iPhone has only one audio sample that it repeats every time you tap on the virtual key, WP7 plays one of eight variations in a loop.
Although it’s ever so slightly different, Microsoft claims they’ve done this so its more organic like footsteps down a hallway – the same but different, and less “obnoxious” if you were to press the backspace repeatedly. Matthew also claims feedback from “power typers” suggests the sounds deliver a better tactile experience.
http://www.youtube.com/watch?v=M6e5kPDe5zI
For more info.
seconded on the sw keyboard. And the keyboard is also good. It keeps up with fast typing and multitouch as well as text correction is smooth as butter. This has been the most pleasant sw keyboard I have ever used.
I think I can say another good touch is the start menu button. It is so good for quick one handed operation especially on the dell venue pro. I have to put a bit of force so its not pushed by mistake
Again nice touch
Xylias said:
It turns out, every time you type on the soft-keyboard in WP7, it’s a subtly different sound. Whereas the iPhone has only one audio sample that it repeats every time you tap on the virtual key, WP7 plays one of eight variations in a loop.
Although it’s ever so slightly different, Microsoft claims they’ve done this so its more organic like footsteps down a hallway – the same but different, and less “obnoxious” if you were to press the backspace repeatedly. Matthew also claims feedback from “power typers” suggests the sounds deliver a better tactile experience.
http://www.youtube.com/watch?v=M6e5kPDe5zI
For more info.
Click to expand...
Click to collapse
I didn't realise that about the keyboard sounds, it definitely does contribute to the pleasant nature of the typing experience
I really like the sense the phone gives (through its use of the panoramic screens) that you're the one controlling the phone, not the software. For instance, the speed at which you move through the content is dictated by the speed at which your finger moves, not some predetermined speed associated with an invisible switch you flip when your finger swipes across the screen.

Categories

Resources