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.
Related
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?
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?
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).
Hello there,
I'm interested in developing image processing software for android devices. So far I got OpenCV and a simple example app running on my HTC Desire. It finds ellipses in realtime in a camera preview surface. The speed is OK (15 fps) and I expected the performance on the eeepad Transformer to be even faster. But the opposite is the case. The native (c++ implementation) camera preview that worked well on the Desire ist horribly slow on the transformer.
For me it's seems like the app has no full priority. Is there a way to give an app exclusive priority so it can use more CPU power? Are there some hidden performace switches on honeycomb I have to activate in order to get this app going faster?
thanks in advance for every answer or even hints to other forums.
SirHoop
I check the debug log of the native processor, apperently it processes the images with up to 30 fps. Unfortunately that is not the framerate I see on my display. This let's me conclude that there is a fundamental problem with the CameraPreview class on the transformer.
Apparently this is an OpenGL ES problem. The NativeCameraPreviewer of OpenCV uses a GLSurfaceView to draw the modified camera image. I use an additional GLSurfaceView to render some 3D content on top of that preview surface. So, 2 GLSurfaceViews are active and somehow that causes problems on either this specific device or android 3.0. On an HTC Desire running 2.2 this problem did not arise.
That's all I got, unfortunately I could not fix it so far. Just deactivating the second GLSurface made the camera preview smooth.
(please note: I would like to post this to the developer forum, but since I just registered, I'm not allowed to do so. furthermore, I'm not allowed to post direct links (see below))
I would like to announce a new library for GPU-based processing on mobile systems – ogles_gpgpu.
As many of you know, it is often beneficial in terms of performance and energy efficiency to execute certain processing tasks on the GPU instead of the CPU. This is especially the case for image processing tasks. ogles_gpgpu enables fast and portable, GPU-powered processing by using OpenGL ES 2.0 shaders.
Since transferring data to and from the GPU is often a bottleneck for GPU processing, platform-specific fast texture access is also implemented. The library is written in well documented, clear C++ code. An interface for Android systems via JNI is provided. Example applications show how to use this library. All code is LGPL licensed.
There are several scenarios on how to use this library: You can for example pass image data (or arbitrary byte data) to ogles_gpgpu, which creates an OpenGL texture from it. You can then process it on the GPU by applying a series of filters (OpenGL shaders) on it. This kind of rendering happens off-screen. Afterwards, you can lock the result data and obtain a pointer to it. You can then copy this data for future processing or directly analyze or modify it. Another possible scenario is to directly pass an OpenGL texture ID as input for ogles_gpgpu. This is for example beneficial if you can obtain camera frames as OpenGL texture from the camera API of your target platform (both Android and iOS allow this and example projects or provided for this). Now ogles_gpgpu can directly run the filters on this camera frame texture. This can happen off-screen or optionally on-screen, which means that the result image is also displayed to a render surface. After processing on the GPU side, you can access the result data again as described in the first scenario. By this, you can do further CPU-based processing of the result data. This is for example necessary, if certain algorithms can not (efficiently) be implemented as OpenGL shaders.
At current development stage, there are not so many image processing filters implemented, yet, but this is about to change in the future. The most important thing is that a portable architecture for GPU-based processing is available, which allows fast texture access by using platform-specific optimizations.
You can check out the project on github: github.com/internaut/ogles_gpgpu
More information can be found on my personal website: mkonrad.net/projects/ogles_gpgpu.html
Thank you.