[Tilt, TyTN II, MDA Vario III General] herg62123:
TWO OF THREE PAGES

(Quoted from HTC TOUCH DUAL found here http://www.htc.com/product/03-product_htctouch_dual.htm):

Delivering a revolutionary touch experience that will change the way you use your phone, the HTC Touch Dual™ combines an intuitive touch screen and slide-out keypad within a stunning design.

Everything you need is at your fingertips. With the push of your thumb, the front panel of the device slides up to reveal a handy smart-sized keyboard. If you prefer using touch, then the revolutionary TouchFLO™ interface lets you quickly browse through e-mails, messages, music and images by using finger gestures, making navigation a breeze.

With the Live HTC Home™ screen, information such as time, new messages, weather updates, and missed calls is just a touch away. Connect using 3.5G, which is 9 times faster than 3G -- wherever you are.

PLEASE PAY CLOSE ATTENTION TO THE BOLD, HIGHLIGHTED, AND UNDERLINED section above.

This is an example of what HTC claims these devices do but in fact they don't. This is why need help to fix these problems.

From people upset with poor drivers says the following by testing their devices and the results show differently than what HTC claims from their website. The following explains just the opposite from HTC WEBSITE's CLAIM:

(THE FOLLOWING INFORMATION IS QUOTED FROM THE FOLLOWING WEBSITE: http://www.htcclassaction.org)

Display driver background

Here is some information on how display drivers are generally built up in Windows Mobile devices, as this will be referenced several times later on in this page.

Generally speaking, a complete set of display drivers (which indeed includes multiple drivers) are built up out of one main 'core' driver that does most of the actual talking to the hardware, and several other drivers that provide specific functionality (like GDI, DirectDraw, Direct3D, GAPI, etc) which use that 'core' driver. This is done because some part of the drivers must be responsible of keeping track of all the surfaces, make sure they all don't interfere with each other, etc. Obviously, the easiest way to do that is with such a 'core' display driver. Not having such a driver and having every functionality specific driver just do what it wants could result in weird behavior, and having them all communicate without such a core driver would be a likely source for heavy overhead.

An example of this is the LG KS20 (a device by LG also based in the MSM7200 chipset from Qualcomm). The 'core' driver here is called ahi2dati.dll, which is in turn used by the GDI / DDI, OpenGL ES, and Direct3D drivers. The latter doesn't use it directly, but that is because it's calls are mapped to OpenGL ES calls.

If you look into the complete software system deliverd on the affected phones we have personally tested, this complete system is absent. This is already a good clue that nothing uses the acceleration provided by the MSM7200/MSM7500 platform.

You will notice that on this page it is said several times that the performance from certain drivers is so low it is hardly possible the driver in question is hardware accelerated. This ofcourse compared to the specifications of the MSM7200/MSM7500. It may still be that a very small part of these drivers actually is hardware accelerated, but if that were the case, they did a downright shameful job of it.

Touchscreen

This issue is a bit tricky to get to show at first, but we have found a way to demonstrate it fairly easily. To replicate this, you will need Dynamix 3D Benchmark 1.0b and optionally My Mobiler.

Install Dynamix 3D Benchmark on the device. Note: though this is called a 3D benchmark, it does not use Direct3D or OpenGL ES. This is a benchmark using GAPI that tests Dynamix' own software rendered 3D engine. Furthermore, the benchmark itself uses a very simple 3D object. Do not try to make any assumptions whatsoever what this benchmark means to either software or hardware rendered 3D scenes on these devices, as all those assumptions would mean nothing.

You can find the application itself in Start --> Applications --> Games --> Dynamix 3D Benchmark. First, simply run it and let the benchmark do it's thing - this takes 100 seconds. At the end you will see a screen with the benchmark results. These were our results:

Average: 78 fps

Min: 19 fps

Max: 86 fps

Ofcourse, the important number here is the average FPS counter. Min and max are too easily influenced. Now, run the benchmark again, but when it starts, put your stylus to the touchscreen and start making circles with it, continue making the circles until the benchmark ends. When doing this, you will immediately see the FPS counter at the topleft of the screen drop. Again, these are our results:

Average: 32 fps

Min: 12 fps

Max: 76 fps

As you can see, the performance influence is enormous. Performance is halved due to use of the touchscreen. Next, we confirm that this is indeed a touchscreen issue. We do this by using My Mobiler. Install My Mobiler on your PC, and make sure your device is connected through USB (not Bluetooth) and ActiveSync. Use My Mobiler to connect to your device (it will install itself on the device through ActiveSync) and you can get your device's display on your PC screen. Start the benchmark again (through the screen on your PC) and let it run. Our results:

Average: 65 fps

Min: 51 fps

Max: 84 fps

Due to My Mobiler and the resources it takes capturing the screen and transmitting it to your PC, the FPS count is a bit lower, this is to be expected. Now we do the stylus-circling trick, but through My Mobiler. Start the benchmark and on the computer press down the left mouse button in your mobile device's screen and keep circling your mouse in that area, for as long as the benchmark runs. Our results:

Average: 62 fps

Min: 38 fps

Max: 80 fps

These results were a bit lower than the previous one, which can be explained through the inaccuracy (no two benchmarks are ever completely the same) and the added processing due to the mouse input. Now the trick with this is, that My Mobiler works by simulating the stylus input, by directly sending the relevant window messages to the foreground application. This means it completely bypasses the touchscreen hardware as well as software (the driver). As the issue is not apparent now, we have proven that the issue is indeed due to the touchscreen, and not due to any other subsystem.

A next step would be proving without a doubt that it is a software (driver) issue and not a hardware issue. This will require some ROM cooking and hacking to do, and we are still looking into it. It is however very unlikely that this a hardware issue.

Camera

The camera is a complicated item, as it depends on the camera hardware, the radio ROM, software drivers, and normal software. Most users will be able to easily verify that the camera application is very slow. Some devices' software seems to perform better than others, and quality and speed also seems to differ with different radio ROMs. The point remains that the camera is almost unusable, even with the fastest combination of HTC software and radio ROMs, and especially with the stock software from the HTC TyTN II. Ofcourse, having slow display drivers will negatively affect this issue, as the software will update a full screen image constantly. When this is slowed down due to the display drivers, the camera application is also slower. It's still doubtful, however, that this is an issue having to do with only the display drivers, there's likely a lot more involved.

GDI / DDI

It is very hard to verify wether this driver is hardware accelerated or not with absolute certainty, as it does talk to hardware in any case. However, seeing the system mentioned above is absent and the performance of this driver is abysmal, it is highly doubtful it is. Some dissembling and debugging can confirm this is not the case, but that is beyond the scope of this page.

DirectDraw

The DirectDraw driver provided on the devices we have tested is the default DirectDraw driver provided my Microsoft. One way to verify this is by dissecting the ROM from one of the devices. You will notice that ddraw.dll is system driver, not an OEM one. Note though that it is not necessary for the DirectDraw driver to use hardware acceleration directly to take advantage of a device's hardware acceleration. As of DirectX 8, which is the base for Mobile DirectX, DirectDraw has been integrated with Direct3D. DirectDraw's hardware acceleration is thus dependant on other drivers having hardware acceleration.