Database Info

What is HTC's problem with Camera APIs?

I'm quite pissed.
Before Windows Mobile 2005, HTC did not make their camera API public, so developers could not make use of the camera.
This all changed with WM2005 and the introduction of DirectShow. For devices released in the first year (since release of WM2005), this meant that one could "simply" use DirectShow to access the cameras.
But then HTC fell back to old habits again:
The HTC TyTN (Hermes) reports only a single video mode via DirectShow: 160x120 at 7.5 fps, which is a joke. Furthermore, trying to access the front camera via DirectShow fails too: It is simply not exposed (enumerated) at all.
The HTC Mteor (Breeze) goes even one step furher: It does report 160x120 and 320x240 (both at 15 fps), but actually both modes deliver pictures at 160x120. For the 320x240 mode, everything seems to work fine: IMediaSample tells that the picture is in that resolution. The memory buffer has the correct size (320x240x12bits), but the image in the buffer is really just 160x120.
Of course I tried several ROM versions (HTC, i-mate, etc.) but no chance.
So, I'm quite pissed. I already tried calling HTC but didn't get very far (which makes sense if these restrictions are on purpose...)
Daniel

No comments on this?
Nobody every using DirectShow?
I guess I also wouldn't do it if I wasn't force to...
Daniel

So with simple words if you want to use WM5 camera api in your application you can not do it in any HTC device

So how did the makers of CoolCamera go about? I was kinda under the impression that it used wm5s camera api, or am I wrong?

I think they've rewritten the interface from scratch. Look into the CPU developers' manuals. Not a small endevour!
V

CPU Developers' manual
Hi Vijay555,
Would you be so kind to post a link to where I can get this manual ?
Thanks in advance!

I don't think anyone wrote anything from scratch nor do I think this has much to do with a CPU manual... the devs at CoolCamera may have *somehow* managed to get their hands on the infamous HTC TyTN camera api... what exactly are you referring to when you mention the CPU manual?
Also, has anyone ever found a location where this api may be available or a means to get it? HTC developer support is non existant.

Eric, what makes you so sure that they didn't write it from scratch? Maybe they did acquire illegally or otherwise HTC's intellectual property, or maybe they just did what other manfacturers do and wrote some code.
Look at the device support - it's not a single device, it's many, across many different CPUs (Intel, Omap, Samsung), across many different camera sensors and support chips. However, implementation of a camera at software level is not impossible: how else do companies sell their sensors and chipsets?
http://www.ovt.com
Ask the sensor manufacturer, they'll give you chips specs, schematics, implementation code and draft driver code.
Then, look up the SC32442A developers' manual and you'll see that it encompasses a camera interface, again with necessary schematics and hardware IO information.
Sure it's hard to write a camera interface, but once you've written one, it gets easier to support others.
V

they need to continue writing then because my camera application frequently fails in that pictures are corrupt, can't be viewed, and the picture review is just black

Sure it's hard to write a camera interface, but once you've written one, it gets easier to support others.
V
Click to expand...
Click to collapse
What kind of effort are we talking about here? Days? Weeks? Do you think this would need to run in kernel space, or we could get away with user space?

HTC Performance - Fact Or Fiction The True Story...

Ok, I've seen numerous questions about the app called HTC Performance & have disassembled the executable. While my knowledge of these thing is by no means great, I have found some very interesting functions.
Maybe someone with more reverse engineering & code experience can take a look, but with IDA Pro there are some very interesting functions & strings.
Some of the calls & code are deprecated & no longer used in WM6 + but some of them are.
It is possible, especially for evB equiped roms, that this prgram acts like a server of sorts for some programs & processes. But being as it is initiated with Smartphone only functions I doubt it.
some of the more interesting functions in the HTC Performance app are:
SHInitExtraControls Which appears to be for Smartphone only
GetSystemMetrics WM6 Pro valid - Gets System Width & Heigth in pixels. Posible uses include program optimization based on the appropriate pixel returns
CreateMutexW - coredll - used to connect to core via net cf for obtaining device info- Usually eVB related apps use to call coredll info
memmove = takes more memory than memcpy but may be used to ensure unicode strings not used on odd memory addresses, this could increase speed on apps that incorrectly do this.
InterlockedCompareExchange, InterlockedDecrement, InterlockedExchange, InterlockedExchangeAdd, and InterlockedIncrement = functions provide a simple mechanism for synchronizing access to a variable that is shared by multiple threads. The threads of different processes can use this mechanism if the variable is in shared memory.
InterlockedCompareExchange = function performs an atomic comparison of the Destination value with the Comperand value. If the Destination value is equal to the Comperand value, the Exchange value is stored in the address specified by Destination. Otherwise, no operation is performed
YAXPAX = can speed up access of written C++ Code
ReleaseMutex = Mutex functions are used to release shared functions
EnumWindows = (..) to execute a task. EnumWindows (..) enumerates through all existing windows (visible or not) and provides a handle to all of the currently open top-level windows. Each time a window is located, the function calls the delegate (named IECallBack) which in turn calls the EnumWindowCallBack (..) function and passes the window handle to it. Not sure howthis is used though.
LoadAcceleratorsW = ??? Appears to be old CE function. Deprecated???
realloc = String Optimization
malloc = RAM Allocation
GetDeviceCaps = gets dev info, can be used to the optimize redraw based on device constraints already known
LocalReAlloc = This function changes the size or the attributes of a specified local memory object. The size can increase or decrease.
EnterCriticalSection = The threads of a single process can use a critical section object for mutual-exclusion synchronization. The process is responsible for allocating the memory used by a critical section object, which it can do by declaring a variable of type CRITICAL_SECTION. can grant exclusive access to memory
ReleaseDC = This function releases a device context (DC), freeing it for use by other applications. The effect of ReleaseDC depends on the type of device context.
Again, I am not a programmer, I know a few things, & am pretty competent with the lower operations of firmware, but the rest of the CE code is not my cup of tea. There are many more functions in HTC Performance. These are only a few functions found after a brief 20 minute peak.
But maybe, maybe, some of the function calls can help us to understand if this app can be moddified to properly function on the Kaiser.
It is possible that on some evB enabled apps, that maybe some of the HTC Performance app are retained & possibly function, that is pure speculation though, & again I doubt it.
Any CE code experts out there wanna take a look? I have, & based on what I've seen, I'll have to say FICTION!

Info
Hi,
Since I haven't really had time to see whats new and all I haven't the foggiest idea what HTC Performance is/what it is supposed to do.
But I can tell you that the functions you listed are not special in any way. Most of them would appear in every application that displays anything on the screen. For instance getting system metrics is required for any application displaying scroll bars, etc. All the interlocked and critical section stuff is just thread synchronization.
But that's OK, the use of windows APIs really doesn't mean much, other than the application runs on Windows...its the non-API stuff that defines an application. If the application you're looking at writes changes to registry keys, etc. you may want to look into that as those would be the lasting changes to the device.
Cheers,

Why is there concurrency related stuff in there? Surely that should all be handled by the operating system, rather than a running application? (That said, most of my concurrency knowledge is either theoretical or based at a high level, so I could be wrong here).

High Performance Cab
You can also check this thread...
http://forum.xda-developers.com/showthread.php?t=366792

Quentin- said:
Hi,
Since I haven't really had time to see whats new and all I haven't the foggiest idea what HTC Performance is/what it is supposed to do.
But I can tell you that the functions you listed are not special in any way. Most of them would appear in every application that displays anything on the screen. For instance getting system metrics is required for any application displaying scroll bars, etc. All the interlocked and critical section stuff is just thread synchronization.
But that's OK, the use of windows APIs really doesn't mean much, other than the application runs on Windows...its the non-API stuff that defines an application. If the application you're looking at writes changes to registry keys, etc. you may want to look into that as those would be the lasting changes to the device.
Cheers,
Click to expand...
Click to collapse
No, registry would not necesarily be the place to look. For this application the registry will only report whether or not the App is running or not. It is supposed to be a speed optimization application. My thought were that it could possibly be acting as a server of sorts, handling some thread optimization & resource allocation. Correct though, most of those API's are importing device info, beyond that, I am lost as to how it handles it, if it does at all. That said, there are many things that don't show up in the registry & many things can't be altered via the registry b'c they are set or handled before initialization or loading of the registry, possibly thru the OAL. Even tougher to say in a two chip device with as little known info as the msm7xxx processors. If anyone with real coding knowledge could take a look at the executable & see just what it's doing with the info, that would be great.

dperren said:
Why is there concurrency related stuff in there? Surely that should all be handled by the operating system, rather than a running application? (That said, most of my concurrency knowledge is either theoretical or based at a high level, so I could be wrong here).
Click to expand...
Click to collapse
That is indeed the center of my question & also what leads me to question how the app functions. Is it playing a role in thread priority optimization, & possibly redraw based on the polls, or is it just a partially gutted application miising a ton of registry data that never worked?

Rotating an image, windows mobile, vb.net

So I have been messing around with windows mobile development (in vb, don't hate me, i have grown accustomed to vb because of work). Anyways I come to a point where i would like to use the graphics object to draw an image and rotate it on occasion based on the state of the program. My instincts told me to use System.Drawing.Drawing2D.Matrix object to create that rotation but as it turns out it appears .net compact framework doesn't support that object.
So my question then is, is there any other method for rotating an image as i draw it. I can program in other languages as well if that is what is required, I was really only using vb because it was easy.
Any ideas?
Thanks

don't know about vb but
in c# i would look for an event to subscribe to
which would be fired when the orientation changed
or the resolution changed or some control resized

Sorry the question isn't related to orientation or resolution. I know when I want to rotate the image.
I will give more information, the image is a compass and I want to rotate the compass image based on GPS data received (Calculating the angles is not the problem either). Once I know that say I am 10 degrees off of north, i want to rotate the image of the compass so that north is still pointing north.
In my desktop development this would be done in vb or c# using the System.Drawing.Drawing2D.Matrix class, using Matrix.Rotate and them applying that matrix to the graphics object before i draw the image using graphics.drawImage().
Now the problem comes when I move to the mobile platform where System.Drawing.Drawing2D.Matrix does not exist and is appariently unimplemented. So then my question is, are there any other API's on the Windows Mobile Platform that support Rotation of an image by an arbitrary angle, and if not does any one have any good ideas where to start looking for implementing the rotation manually myself.
Thanks in advance

That's one of the annoyances with the .NET compact framework, not all of the PC .NET framework is implemented, and sometimes it's the bit you really want.
Time for a different angle on the problem. Create 36 compass images 10 degrees apart and store them all in an ImageList object. Pull the one you require out of it when the heading changes. Not quite as elegant as the Matrix class, but it may have to do.
The other approach would be to use DirectX drawing. The coding to do it, would probably involve a very steep learning curve, but not having dabbled in this arena yet, I can't offer much help.

The ImageList object in the .NET compact framework does not support ImageList.Draw(), (darn!, see previous post), so you would have to create a PictureBox object or similar and use :-
PictureBox1.Image = ImageList1.Images;
Where i is the index of the image you want to use. (0 to 35)

Thanks for the suggestions, I did end up predrawing the images of the compass. At the moment I went ahead and made 360 images but I am surely going to cut that down quite a bit. The question then becomes smoothness vs space. But either way you shake it it is working.

Touchscreen Driver improvements (Touch.dll)

Touchscreen Driver improvements (Touch.dll)
This Polaris thread contains a new Touchscreen Driver and various registry keys to improve touchscreen response.
http://forum.xda-developers.com/showthread.php?t=446126
***WARNING***
Unfortunately, at this stage this improved touchscreen driver is not compatible with Kaiser Roms. Hopefully further testing and development with change this.
__________________
According to my Kaiser Taskmanager (I have tried this on at least 5 Roms and is a well know HTC bug on many devices), just placing pressure and motion on the touchscreen uses an addition 50%+ CPU usage even if no function is being accessed by touching the screen. Touchscreen driver is also at Highest Priority setting by default. This is a major cause of sluggishness on HTC devices as all tasks, including screen re-draws is suspended in favour of the touchscreen mindlessly using 50%+ CPU.
Creating this following registry keys can lower the CPU priority but the screen is very unresponsive -
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch
(DWORD)
Name = "Priority256"
Value = "255"
Name = "PriorityHigh256"
Value = "255"
The following registry keys (Original Microsoft value that can be found at MSDN for a normal driver) lower the CPU priority but still maintain usability (CPU can still reach 50%+) -
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch
(DWORD)
Name = "Priority256"
Value = "109"
Name = "PriorityHigh256"
Value = "109"
A soft reset is required to test these values. I am currently testing different values to find the best blend between screen response and screen refresh rate.
There are other registry keys which may help as well. I look forward to your feedback.
I am not a programmer but I started this thread in the hope that one of our highly talented chefs would be able to make a port of Polaris driver for Kaiser. I have tried playing with the registry and it does have an effect but there are trade-offs between graphics performance vs touch screen response.

TITAN-23 said:
Touchscreen Driver improvements (Touch.dll)
This Polaris thread contains a new Touchscreen Driver and various registry keys to improve touchscreen response.
http://forum.xda-developers.com/showthread.php?t=446126
According to my Kaiser Taskmanager (I have tried this on at least 5 Roms and is a well know HTC bug on many devices), just placing pressure and motion on the touchscreen uses an addition 50%+ CPU usage even if no function is being accessed by touching the screen. Touchscreen driver is also at Highest Priority setting by default. This is a major cause of sluggishness on HTC devices as all tasks, including screen re-draws is suspended in favour of the touchscreen mindlessly using 50%+ CPU.
Creating this following registry keys can lower the CPU priority but the screen is very unresponsive -
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch
(DWORD)
Name = "Priority256"
Value = "255"
Name = "PriorityHigh256"
Value = "255"
The following registry keys (Original Microsoft value that can be found at MSDN for a normal driver) lower the CPU priority but still maintain usability (CPU can still reach 50%+) -
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch
(DWORD)
Name = "Priority256"
Value = "109"
Name = "PriorityHigh256"
Value = "109"
A soft reset is required to test these values. I am currently testing different values to find the best blend between screen response and screen refresh rate.
There are other registry keys which may help as well. I look forward to your feedback.
Click to expand...
Click to collapse
Im thinking about doing the opposite. I want faster touch response. lol

TheParadox said:
Im thinking about doing the opposite. I want faster touch response. lol
Click to expand...
Click to collapse
Actually, the touch "user experienced" responsiveness is slower if the touch.dll has too high a priority as the screen refreshes slow down (lower frames per second on scrolling and animations).
Have you noticed that frames per second DECREASE dramatically the longer you touch the screen? This is because screen re-draws (refreshes) are at a lower priority to the touch driver. The touch driver is hogging the CPU. This makes the interface sluggish and slow.

resulted in a completely unresponsive touchscreen in my Kaiser .. hard reset was needed. Perhaps incompatible with the rom i was using? (Ultimate X v7 .. excellent rom btw).

bump
would love to see some progress made on this

When i saw the title i thought there was a new driver that was less cpu intensive . Oh well, i should give this a try and see if it is compatible with josh's kitchen.
Edit: there is a driver, but work on it appears to be discontinued?
This guy was doing the winmo world quite a favor by attempting to fix a problem that plagues us all (or at least the HTCers among us.) I wonder if htc will fix this eventually.

I am not a programmer but I started this thread in the hope that one of our highly talented chefs would be able to make a port of Polaris driver for Kaiser. I have tried playing with the registry and it does have an effect but there are trade-offs between graphics performance vs touch screen response.

marbella property
First Time it is worked for me, but now it is look like i have jailbreaked my device

bump.
as for me 2d drivers more important that 3d one.

It works
I'm currently using a value of 109 as recommended and feel it more responsive.
The ROM i'm using is Josh 21806 Full.

Enabling 2D Hardware Acceleration in all Apps?

I'm sure the vast majority of the users who frequent this section are familiar with Honeycomb's new 2D hardware accelerated graphics pipeline, replacing the older (and considerably slower) Skia 2D software-accelerated rendering engine.
Currently, to take advantage of the 2D Hardware Acceleration, each application must have the following in its AndroidManifest.xml:
Code:
<application android:hardwareAccelerated="true">...</application>
Additionally, the 2D HW Acceleration pipeline can be turned on and off for individual activities within each application:
Code:
<activity android:hardwareAccelerated="false" />
Furthermore, you can control the 2D acceleration on the window and view levels.
Unfortunately, the vast majority of applications have not added that flag. Romain Guy explained why he thought that it was a bad idea to have Android default to enabling the new pipeline, citing custom drawing code as a concern. I'd still like to give it a whirl.
Romain Guy said:
It is not turned on by default for compatibility reasons. Not 100% of the Canvas API is supported when turned on (although the missing parts are very few and rarely used) and there might be bugs in the new implementation. There are also new constraints (for instance if you try to draw a bitmap larger than the maximum OpenGL texture size, it will fail.)
The new rendering pipeline also uses native display lists for each View, which triggers bugs in some apps. For instance, if a View relies on its parent to invalidate() to redraw itself, it's a bug in the app, but it "works" without hardware acceleration. It will however not work with hardware acceleration on.
Our goal is to make hardware acceleration on by default as soon as possible but we do not want to break apps. That said, apps using standard views and APIs should work just fine.
Click to expand...
Click to collapse
Does anyone have any idea as to whether a parameter could be modified on a system file in order to force all applications to behave as if they have the android:hardwareAccelerated flag turned on?
Thanks!

Yes. Mobile. Will explain later. And by yes I mean probably.

Let's pretend that the reader has never heard of "AndroidManifest.xml".
How are we supposed to know where it is and how to edit it? I've done a complete search of the tablet and it is nowhere to be found.
I am trying to enable hardware accel in MythFrontend.