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?
Hello,
I've spent the last month trying desperately to find a free 2D (or 3D, but not required) graphics API I can use for high performance games on Windows Mobile. I initially set about trying to find a managed API to use, but now I've broadened my search to include any API (that I can call from C++ or .NET), and I'm still struggling to find anything.
The options seem to be:
- GDI: not nearly fast enough for high performance games
- DirectDraw: probably OK, but doesn't seem possible to use this on my HTC Touch Pro 2 due to memory problems (see http://blogs.msdn.com/windowsmobile/archive/2009/04/17/twisted-pixels-3-memory-mysteries.aspx -- I've got the same problem and have not yet found any way to work around this)
- Direct3D: no hardware driver on my Touch Pro 2, this renders about 0.2 frames per second in the samples, which is not good enough
- OpenGL: I've tried and tried, and can't get any samples working for this. The closest I've found is the tutorials here: http://www.zeuscmd.com/tutorials/opengles/index.php, but these all fail with an error, "Unable to create OpenGL|ES context" as soon as I run them (or alternatively using the "Ug" version, I get no window appearing at all).
Does anyone have any suggestions as to how I can progress from here? I really want to write some Windows Mobile games, but I can't even get started. :-(
Thanks,
Adam.
For 'better' graphics performance have a look at the 2D/3D Driver Development for MSM720X devices!
After installation of this driver pack try my OpenGL test app (source also available) found in my sig! Installing this driver pack will increase d3d performance, too!
Hi heliosdev,
Many thanks for posting the sourcecode for your OpenGL test -- I have that compiling very nicely here and producing very promising results too. I think this may finally be the answer I've been looking for.
Do you have any idea how much of a performance hit using PInvoke to interact with OGLES is likely to be? I don't know whether PInvoke is slow to use or not, but it strikes me that it may be slower use it hundreds of times per frame compared to coding directly in C++ and not needing to PInvoke at all..?
Thanks again,
Adam.
For comparison NuShrike implemented torus test in C++. As you can see the difference is 'minimal' even NuShrike optimized it using vertex buffer objects (I'm using standard vertex arrays and just triangles, i.e. no triangle strips).
I have a simple question about Android in which I have not found the simple answer to... (Although I think I know, I just want some clarification). I recently switched over to Windows Phone 7 because of various reasons, I will not name them here as that is an entirely different subject, however one of the reasons i switched was because of overall responsiveness of the OS. Why does Android's touch response feel sooo clunky? Yeah transitions and app launches are nice and quick, but I mean like pinch-to-zoom, and scrolling... I have played with the latest and greatest both rooted (with and without custom rom) and non rooted (with or without OEM UI), Motorola Xoom, Atrix 4G whatever is being claimed latest and greatest. But no matter what they all have the same touch response lag no matter what. This, believe it or not, is a major deal breaker for me, and before the majority of you speak, I'll speak for you; "why is something so simple and small, barely even considered a nuisance, be such a nuisance?" for me, i love fluidity, so, it just is. At this question however i do retort; if its such a "simple" or "small" nuisance, why can't it "simply" be coded to feel as fluid as Windows Phone 7, or iOS?
Luisraul924 said:
I have a simple question about Android in which I have not found the simple answer to... (Although I think I know, I just want some clarification). I recently switched over to Windows Phone 7 because of various reasons, I will not name them here as that is an entirely different subject, however one of the reasons i switched was because of overall responsiveness of the OS. Why does Android's touch response feel sooo clunky? Yeah transitions and app launches are nice and quick, but I mean like pinch-to-zoom, and scrolling... I have played with the latest and greatest both rooted (with and without custom rom) and non rooted (with or without OEM UI), Motorola Xoom, Atrix 4G whatever is being claimed latest and greatest. But no matter what they all have the same touch response lag no matter what. This, believe it or not, is a major deal breaker for me, and before the majority of you speak, I'll speak for you; "why is something so simple and small, barely even considered a nuisance, be such a nuisance?" for me, i love fluidity, so, it just is. At this question however i do retort; if its such a "simple" or "small" nuisance, why can't it "simply" be coded to feel as fluid as Windows Phone 7, or iOS?
Click to expand...
Click to collapse
I will try to answer since I've been using android before. android now as I believe is still in development stage. especially because it started from open source, where many developers get involved to participate in android development. unlike windows or the IOS platform. development is only done by the company itself through microsoft and apple. Except for third-party application development
android is a system (for run smoothly) with very powerful hardware. so that the source code would require a very complicated of encoding. Its a very difficult job to sync between the needs of software with hardware which is available. and vice versa. in an application such as pinching and scrolling there is more than one command which contains a lot of code. and should be remembered that this is a system. which are all related to each other for the overall operations to run smoothly based on the minimum demand of the hardware required. if there is one character in which is wrong of encoding or difference may cause the application not running properly.
for high-end android device such as Xoom, atrik 4G I'm sure the hardware is not an issue. I'm sure it was more caused by the complexity of encoding in one of the applications listed that is running inside in the whole operating system, making it not running smoothly. because so many commands which must be running at the same time is what make pinching and scrolling activity to be "clunky" like you said. you can differentiate by turning off the internet connection or turn off unnecessary applications running in the background. But I'm sure very soon android operating system will have a system which is more stable and efficient in encoding such as those held by the windows or apple.
My answer may be added by other members of the more expert in these matters. as a newbie, i am just trying to help based on the knowledge I had acquired over the years. CMIIW
Yeah I figured it would be something like that, I owned a Droid (1st gen.) and I had multiple setups from completely stock to my favorite, Cyanogenmod (always on the latest stable build, although I've already flashed CM7 RC2 and its probably the fastest its ever been at 800 MHz) everything was perfect except; scrolling and pinch-to-zoom. The scrolling is almost there, it actually lags for a bit but if I leave my finger on the page, it locks on to that position and stays there, but once I lift it to continue scrolling down or up it'll lag a bit again. The pinch zooming is just horrible no matter what. Unfortunately, given the nature of open source, and coding software in general, there is no such thing as "finished" software, so since this is open source, and the software is basically written to run on "nearly" whatever device you choose to flash it on, i don't think that problem will ever be solved. However, if Android does eventually reach that richness of responsiveness, then i will more than gladly switch back.
issues of a system running smoothly is different from one device to another device.
due to the wide variety of different android devices that causes the emergence of issues on the system stability. it was time to google as the main developer sets the standards for the development of next android os. while there is no standardization of hardware is set by google. it will be very difficult for other developers to write code/adjust performance in the operating system command. all this time writing code is must be adapted to the device from vendor itself. This will bring up the differences result of writing the code on other devices from another vendors (competitors). so if we running bencmark test or head to head test on both devices from different vendor the result will not be the same.
and if there will be a standarization set by google i believed it will not againts a spirit of an open source
I think the hardware that the WinCE (well...the shoe still fits) and Android phones are made on is essentially the same, in terms of the CPU power, the actual CPUs, the memory and the various other systems (graphics, etc.). Maybe not identical but overlapping classes and performance.
I haven't played with the new WinPhones but have noticed that every Android phone, no matter how fast and how "bare" factory, sometimes goes out to lunch. Apparently that's just the way the OS is written, it sometimes goes off to do other things internally (loading code? checking hardware states?) and you can't do anything except wait for it to come back.
But then again, almost every OS does that at times, including the main Windows OSes. That's just how they are done these days. If you had a cell phone fifteen year ago, you could turn it on and dial NOW. With any of the new cell phones? Can you do a cold power up and have a functioning phone in less than 30 seconds? Uh, no. But they call that progress, because you rarely have to power them off these days.
Every OS has tradeoffs, if the WinPhone makes you happier, by all means do it.
Rred said:
I think the hardware that the WinCE (well...the shoe still fits) and Android phones are made on is essentially the same, in terms of the CPU power, the actual CPUs, the memory and the various other systems (graphics, etc.). Maybe not identical but overlapping classes and performance.
I haven't played with the new WinPhones but have noticed that every Android phone, no matter how fast and how "bare" factory, sometimes goes out to lunch. Apparently that's just the way the OS is written, it sometimes goes off to do other things internally (loading code? checking hardware states?) and you can't do anything except wait for it to come back.
But then again, almost every OS does that at times, including the main Windows OSes. That's just how they are done these days. If you had a cell phone fifteen year ago, you could turn it on and dial NOW. With any of the new cell phones? Can you do a cold power up and have a functioning phone in less than 30 seconds? Uh, no. But they call that progress, because you rarely have to power them off these days.
Every OS has tradeoffs, if the WinPhone makes you happier, by all means do it.
Click to expand...
Click to collapse
I agree with you, I do like both OS's for their own benefits, currently I do like WP7 better than Android and keeps me "happy". However if you notice; that's not my prime motive in starting this thread, I didn't come here to say one is better than the other. I just want to know why those two simple things (scrolling and pinch zooming) are not fluid on Android. You can't use the excuse that it's different hardware because Microsoft is playing that trick too. You can't use the "its busy doing other things" excuse either, while WP7 doesn't have multi-tasking, iOS does (somewhat) so it can go "do" something else but will still feel fluid. In a multi-OEM environment it is up to the OEM to optimize it for the device it runs on, which is why it baffles me that even Sense and MotoBlur and others make performance decline a bit and still has the lag. Shouldn't it be the opposite?
Nothing? So no one can tell me why Android's responsiveness (scrolling, pinch-zooming) sucks?
Luisraul924 said:
Nothing? So no one can tell me why Android's responsiveness (scrolling, pinch-zooming) sucks?
Click to expand...
Click to collapse
The answer is quite simple (and the above replies are miles off the mark). Hardware acceleration.
WP7 has it, Android doesn't.
FloatingFatMan said:
The answer is quite simple (and the above replies are miles off the mark). Hardware acceleration.
WP7 has it, Android doesn't.
Click to expand...
Click to collapse
So the hardware acceleration runs throughout the entire OS? I thought it was mainly just the XNA and Silverlight stuff that was accelerated (I do believe those are different than native OS code, as Microsoft isnt allowing developers to write apps with native code. Future compatibility issues I guess)
Of course it's the entire OS. Why do you think MS's minimum spec stipulations are so high? This is what Windows Mobile was so plagued with, and how MS fixed that problem.
Luis-
"So the hardware acceleration runs throughout the entire OS?"
It isn't so much that the hardware acceleration runs in the OS, but that the hardware itself has certain routines built into it, on the firmware level, so the OS can just call those routines instead of trying to calculate them.
To oversimplify a bit, for instance, a hardware accelerator for "zoom in" might be programmed into the video chip system to automatically tell it "take the 50 pixels around this spot and blow up up to 250 pixels, refresh screen" where the OS would be saying "OK, let's take this spot, draw a square with a 50 pixel radius around it, now let's take each of those pixels and transpose it over twice the radius and go fill..." sending a long slow string of commands, each computed by the CPU.
When the CPU can offload all of that into a simple "zoom" command to the video chip, the CPU is now free to do other things. Like, respond to your next input, or push the next menu onto the display.
When you have ironclad control over the hardware--it can be a great way to make systems faster. And more stable.
Rred said:
Luis-
"So the hardware acceleration runs throughout the entire OS?"
It isn't so much that the hardware acceleration runs in the OS, but that the hardware itself has certain routines built into it, on the firmware level, so the OS can just call those routines instead of trying to calculate them.
To oversimplify a bit, for instance, a hardware accelerator for "zoom in" might be programmed into the video chip system to automatically tell it "take the 50 pixels around this spot and blow up up to 250 pixels, refresh screen" where the OS would be saying "OK, let's take this spot, draw a square with a 50 pixel radius around it, now let's take each of those pixels and transpose it over twice the radius and go fill..." sending a long slow string of commands, each computed by the CPU.
When the CPU can offload all of that into a simple "zoom" command to the video chip, the CPU is now free to do other things. Like, respond to your next input, or push the next menu onto the display.
When you have ironclad control over the hardware--it can be a great way to make systems faster. And more stable.
Click to expand...
Click to collapse
Great answer. Makes sense, thanks. Now given that this is an Android section lets talk more on that, will it ever be possible to have hardware acceleration on Android, Whether it be through custom ROMs or OEM devices?
"will it ever be possible to have hardware acceleration on Android,"
Possible? Sure, I've seen pigs on the wing.<G> Don't hold your breath for it though. Android is an unruly place where even ordinary hardware is often not supported by the OS and software breaks on every new phone. In order for hardware acceleration to work, the OS needs to have routines and drivers for standard hardware, which means locking down a hardware spec. Which is so very Undroid.
Can't see that happening, unless ten year from now someone invents a "standard universal Android cell phone chipset" and all the manufacturers get paid to exclusively use it. That's the ticket--use our chipset, we'll pay you to use it, and oh, yes, it will play one of "our" ads every time your screen turns on. Or you launch a new app. Or place a call.
(See? Things could get worse!<G>)
Here's an interesting discussion...
http://code.google.com/p/android/issues/detail?id=6914
burtcom said:
Here's an interesting discussion...
http://code.google.com/p/android/issues/detail?id=6914
Click to expand...
Click to collapse
Well as far as I read, it was just a bunch of "me too" and "I agree" lol I got bored reading that I still dont think Google has an official statement on the matter do they?
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.
gee i wonder a special someone will come and close my thread again. i read through the forum rules and just couldnt quite match up the reason he gave
right anyway i've completed my review.
im going to post a few points here... those who want more details feel free to ask or visit my blog..it's in my sig
pluses are Pros and minuses are Cons
+++++ battery life is absolutely solid. 1700mah is no longer considered big these days- just look at the GS3’s 2100mah and the Razr Maxx’s 3000mah. And yet on Low CPU (800mhz) setting, the phone lasted 30 hours. on High (1400mhz) the phone lasted 24 hours. This is with autosync off, native email client synching every 15mins, 3 benchmark tests per charge cycle tested and other normal usage scenarios. in other words, other than gaming, there is no need for any frugality whatsoever.
++++ native browser is very fast, smooth and speedy. feels faster than Chrome, even.
++++ notification area is the most minimalistic and yet the most functional yet- the notification comes down only as much as is needed, and within it, there is quick access to all available wifi signals, 2G, 3G and auto network selection options and you can also toggle wifi on or off, data connection on off, GPS, autosync..
+++ FlymeOS is wonderfully user-friendly. Meizu has gone the extra length to ensure most the unnecessary complexities of Android are left out.
++ excellent viewing angles from the ASV (Advanced Super View) panel. colours are fine and contrast levels are as you would expect of any regular LCDs.
++ the 4 inch display resolution (640x960) may not win any awards for having the highest PPI as is the current unhealthy obsession these days, but it was impossible (without extra equipment) to discern the pixel differences. More so, coming from the One X, I no longer need to zoom and adjust for slightly larger text which is what I’m more comfortable with. This may be something to consider for people who don’t have perfect eyesight.
++ native voicemail (it actually bypasses your network’s if you set if to do so) and automatic call-recording are nice features and works seamlessly. To play them back, you either tap the new vmail notification or open up the Recorder app.
------ OS has stability problems- phone crashes and restarts once a day (when I was looking). At first I attempted to find the app that was causing it but really, there’s no reason why the OS can crash and burn because of one little app. There’s got to be something wrong deep down. Meizu needs to fix this.
----- unable to set defaults- that includes Launchers, browsers etc.
----- native browser does not support sharing to other apps- a very odd but an obviously deliberate decision.
--- audio / system stutters slightly when the phone’s been in use for around a day without a reboot. this happens especially when 3G data is in use. Makes for a rather unpleasant media performance, mostly.
-- FlymeOS is overly user-friendly and hid or moved a lot of the useful under the hood features. Fear not- an official vanilla ICS ROM has been promised.
-- glossy display exhibits excessive glare. it doubles as a mirror very well. (as you can probably see in the embedded hands-on video)
-- no app drawer- FlymeOS plays the iOS card a little too close to the chest by repeating the bane of MIUI (well, and itself?). what compounds the issue is that unlike MIUI, Meizu does NOT let you pick an alternate launcher as the default.
Not Happy with Meizu MX4
I hope someone cooks a new ROM so I can get rid of Flyme. I have the International vesrion (Non-Chinese)
Bad
Their Flyme email client is only in Chinese
Their catalog of software is only in Chinese
Their personalization Icon only displays in Chinese
It does not come with a Manual?
The Meizu website is in Chinese
Their predictive dictionary seems like 5 to 7 years ago (it doe snot display simple words and does not remember when I have already corrected something.
Good
Camera access on first screen and time between photos and taking pictures is great
Speed of phone phone because of the better processor is remarkably fast
PLEASE can someone come up with a way to either roll back to Android 4.4 on this device with Flyme of cook a new ROM?
Thanks
yellowchilli said:
gee i wonder a special someone will come and close my thread again. i read through the forum rules and just couldnt quite match up the reason he gave
right anyway i've completed my review.
im going to post a few points here... those who want more details feel free to ask or visit my blog..it's in my sig
pluses are Pros and minuses are Cons
+++++ battery life is absolutely solid. 1700mah is no longer considered big these days- just look at the GS3’s 2100mah and the Razr Maxx’s 3000mah. And yet on Low CPU (800mhz) setting, the phone lasted 30 hours. on High (1400mhz) the phone lasted 24 hours. This is with autosync off, native email client synching every 15mins, 3 benchmark tests per charge cycle tested and other normal usage scenarios. in other words, other than gaming, there is no need for any frugality whatsoever.
++++ native browser is very fast, smooth and speedy. feels faster than Chrome, even.
++++ notification area is the most minimalistic and yet the most functional yet- the notification comes down only as much as is needed, and within it, there is quick access to all available wifi signals, 2G, 3G and auto network selection options and you can also toggle wifi on or off, data connection on off, GPS, autosync..
+++ FlymeOS is wonderfully user-friendly. Meizu has gone the extra length to ensure most the unnecessary complexities of Android are left out.
++ excellent viewing angles from the ASV (Advanced Super View) panel. colours are fine and contrast levels are as you would expect of any regular LCDs.
++ the 4 inch display resolution (640x960) may not win any awards for having the highest PPI as is the current unhealthy obsession these days, but it was impossible (without extra equipment) to discern the pixel differences. More so, coming from the One X, I no longer need to zoom and adjust for slightly larger text which is what I’m more comfortable with. This may be something to consider for people who don’t have perfect eyesight.
++ native voicemail (it actually bypasses your network’s if you set if to do so) and automatic call-recording are nice features and works seamlessly. To play them back, you either tap the new vmail notification or open up the Recorder app.
------ OS has stability problems- phone crashes and restarts once a day (when I was looking). At first I attempted to find the app that was causing it but really, there’s no reason why the OS can crash and burn because of one little app. There’s got to be something wrong deep down. Meizu needs to fix this.
----- unable to set defaults- that includes Launchers, browsers etc.
----- native browser does not support sharing to other apps- a very odd but an obviously deliberate decision.
--- audio / system stutters slightly when the phone’s been in use for around a day without a reboot. this happens especially when 3G data is in use. Makes for a rather unpleasant media performance, mostly.
-- FlymeOS is overly user-friendly and hid or moved a lot of the useful under the hood features. Fear not- an official vanilla ICS ROM has been promised.
-- glossy display exhibits excessive glare. it doubles as a mirror very well. (as you can probably see in the embedded hands-on video)
-- no app drawer- FlymeOS plays the iOS card a little too close to the chest by repeating the bane of MIUI (well, and itself?). what compounds the issue is that unlike MIUI, Meizu does NOT let you pick an alternate launcher as the default.
Click to expand...
Click to collapse
Meizu had a aosp rom or something back then, I've not kept up with the news so I don't know what happened to that..
battery drain is still a problem to this day, sadly.