When the video driver is released, (if there even is one) does that mean its going to fix all of these?
-Keyboard lag
-Touchscreen lag
-Camera lag
-Video lag
-Phone freezing
-Battery life quickly dieing
-Landscape to portrait ... and other way around..faster..
Just wondering..
Thanks
No proof on most... but keybaord lag.... not likely!!
Try turning off the auto-correct or auto-insert / guess thingy. (or change it to 4-6 letters before it guesses the word you want!)
the other fixes will depend what you already have done (ie there is a newer camera app on here, if you dont have it - it might resolve your camera problems etc etc).
I cant see it fixing the touchscreen lag - unless the device is busy drawing pcitures for you whcih is why its slow to respond.
Phone freezing.... could be so many things!! who knows
Video lag - possibly, maybe even probably. but it depends on why the lag is occuring, and in what sense you mean video lag (call, record, playback etc etc). Apparently there is a problem with the main camera in video mode in poor light situations, however the front camera doesn't have the same problems (although equally doesn't have the same output)
Bat life... god knows! what are you doing? all movie playback? quite probably! All standby with no screen on, just waiting for your mum to call once a week? then not very likely!
screen switching - almost certainly!
Really, it will depend entirely on what you use your phone for, and what you have done to your phone to start with (or what else you do at the same time as any dirver install)
Will a quad sli gfx setup make my computer display look better? Depends entirely! if i run in a CLI - then no!
Hallo,
I'm new to PPC and realised the scrolling and viewing of sms & mms is very slow. . Initially I thought it was normal for PPC, but my friend told me is abnormal after he view it.
Any advise please.
Good day
Most likely related to the lack of drivers for the Kaiser.... but I'm sure someboday else can confirm.
Audio said:
Most likely related to the lack of drivers for the Kaiser.... but I'm sure someboday else can confirm.
Click to expand...
Click to collapse
Mmm. And that's based on what precisely? Actually it's probably unlikely to be due to the drivers. ********* Edited for pettiness.
Some people are tending to attribute problems to video drivers and little help or thought is being put into what the real cause of problems may be.
This is the same kind of mis-information as when folk were saying the PIE scrolling was down to the drivers (and again it was unrelated to them) OR again when the speed of the camera was put down to the drivers (and again newer software shows this was not the case).
In reply to the OP. Please give us some more detail, circumstances when it happens, how slow is it, are you running any other programs concurrently etc.
Mike
ive noticed that after about 2 hours on my phone (with under 45% memory usage) my txt messages also lag. i write the entire message and it takes like 30 secounds for the message to show up for me to be able to send it. its really annoying
Obviously I'm no Kaiser Wizz, which is why I didn't say "Your problem is because of lack of drivers" (I also missed the sms bit, and thought the issue was only related to MMS, which reading again makes my first post sound insane), but thanks for being patronising in your correcting me and thanks for the mindless sheep insult (which although isn't directly poitned at me, clearly shows I'm the intended recipient).
OR again when the speed of the camera was put down to the drivers (and again newer software shows this was not the case).
Click to expand...
Click to collapse
From what I've seen this has not actually been proven yet, a few HTC Camera Cab's have been released which increase FPS a miniscule amount, but hardly a fix, and not really enough to say that poor Camera speeds are not because of lack of drivers. I'm not saying they definately are, but from your statement you seem to have completey dis-regarded drivers from the issue.
try messing around with the cache tweaks, or flash a new rom
should i increase or decrease the cache in this situation?
Audio said:
Obviously I'm no Kaiser Wizz, which is why I didn't say "Your problem is because of lack of drivers" (I also missed the sms bit, and thought the issue was only related to MMS, which reading again makes my first post sound insane), but thanks for being patronising in your correcting me and thanks for the mindless sheep insult (which although isn't directly poitned at me, clearly shows I'm the intended recipient).
From what I've seen this has not actually been proven yet, a few HTC Camera Cab's have been released which increase FPS a miniscule amount, but hardly a fix, and not really enough to say that poor Camera speeds are not because of lack of drivers. I'm not saying they definately are, but from your statement you seem to have completey dis-regarded drivers from the issue.
Click to expand...
Click to collapse
You are right, my apologies - I have edited my post.
You will be interested to know that a Mod cannot ban himself - I know I tried yesterday but it tells me I'm an "invalid user" - I knew there was something wrong with me
Mike
heh ^
on a serious and honest note - i beleive that the lack of drivers might potentially have something to do with this, but not the camera
rendering an sms or an mms is mostly a one time render into a buffer of sorts which is then blitted onto the screen - obviously the blitting could/would be hardware accelerated but on a 320x240 screen you arent really going to see a significant slowdown due to moving memory around (as thats all is what happens - in well written software at least) unless the bandwidth is really small - some software however re-renders things based on the changing view rectangle - ie a browsers (internet exploder) view port or the icons in the scrolling programs list (i think this might be compounded by the actual icons not being cached by the OS, so it has to pull them from memory and process them every time) - the lag in these programs are caused by the program re-rendering things many times as the view rectangle changes - this would no doubt vastly improve if/when hw accelerated drivers come out.
to talk numbers 320*240*2 (the 2 is the 16bit colour) is 192k of data for a fullscreen of pixels (excluding any z/stencil/accum buffering etc) now i dont actually know the refresh rate of the device but im guessing its either 30hz or 60hz - so every second, worse case senario, 192k * 60 = 11.25Mb/s of pixel data is flying through the memory onto the screen. actually thats not worst case - because often with (proprietry, non-OS) z ordered windowing/raster systems, things are rendered back to front, sometimes with significant overdraw - pushing the pixel rate up even higher.
if you look at the camera in a nice light bright setting, its smooth and functional - this tells me that the memory has enough bandwidth.
programs that arent coded well (ie they just assume hw acceleration and cosntantly rerender) will feel crap and slow on software renderers - programs that are optimised will have considerably less lag on software but would be super sprightly on hardware. does any of this make sense?
as for the camera - same thing, its just a fullscreen blit of memory - i beleive the problem with the camera is the software that is controlling it and applying that superannoying constant nightmode filter - i can only assume this is being done because of the severely low quality of the camera especially in low light conditions (they must feel the need to 'beef it up' with software post processes).
anyway thats my tangential 2p
same problem here is there any solution so far?
OR again when the speed of the camera was put down to the drivers (and again newer software shows this was not the case).
Click to expand...
Click to collapse
From what I've seen this has not actually been proven yet, a few HTC Camera Cab's have been released which increase FPS a miniscule amount, but hardly a fix, and not really enough to say that poor Camera speeds are not because of lack of drivers.
Click to expand...
Click to collapse
So there is a slight fix for the camera. Can someone direct me to where it can be found?
Provoking headline, no? Well, first things first - I also agree to the position that there should be suitable video drivers for the Kaiser; I signed the petition and all. Nevertheless, I may have found another culprit:
I found that the frame rate drops noticeably as long as you tap on the screen (when running "Quake2", for instance). This tells me that the touchscreen is fully operational only if a touch is sensed - at least I wouldn't do this much differently. This is because it is relatively straightforward, fast and power saving a process if you want to sense the presence of a touch, as long as you can ignore the position. But it requires a certain sequence of events in order to determine the X & Y positions. Depending on the type of touchscreen and the supporting hardware, there may be certain processing delays.
Now my suspect is that the processor has to handle the touchscreen all by itself, just with the help of an A/D converter and a few port lines. Which means it may be subjected to a certain processing load if the exact position of a touch is to be analyzed.
Awaiting your comments...
Buster
2 theories about that .
first : if i disable TouchFlo software it should be no issue after that , like thousands of other PDA with "Stylus Only" Touchscreen .
second : if the drivers are aviable , the processor have more capacities for calculating the stylus/finger Position and anything might run smoother ...
also i have noticed that the issue is different in different windows , like in the programm screen its more laggy then in the settings screens
joolsthebear said:
2 theories about that .
first : if i disable TouchFlo software it should be no issue after that , like thousands of other PDA with "Stylus Only" Touchscreen .
second : if the drivers are aviable , the processor have more capacities for calculating the stylus/finger Position and anything might run smoother ...
also i have noticed that the issue is different in different windows , like in the programm screen its more laggy then in the settings screens
Click to expand...
Click to collapse
1st: TouchFlo is off in my case. 2nd: Thats right. I should have added that the drivers may be responsible as well (do you have good ones ;-) ??). But even with the best possible drivers there will be a certain maximum detection speed, depending on the touchscreen architecture (well, a resistive one shouldn't represent much of a problem). I only wondered whether the overall detection speed is so low that it can impact video rendering. Last paragraph: thats another factor (window handler, I 'd say), apart from touchscreen processing - but only as long as these handlers are running. Certain games take over the system almost completely, so there won't be much resources available to the normal windows processing.
yes, this issue has been covered many times over, even at htcclassaction.org
i think the slowness of scrolling the programs menu is not due to no graphics drivers, as the settings menu exhibits no such lag. i suspect te programs menu is jerky as the system must reload icons/data as items come into view - i beleive this is a caching (or lack of) issue.
the touchscren takes up a lot of cpu and as far as i can tell it doesnt matter what program has focus. touching the screen and moving my finger around produces around 50% cpu usage with both touchflo turned on and off (via the settings icon).
fusi said:
i think the slowness of scrolling the programs menu is not due to no graphics drivers, as the settings menu exhibits no such lag. i suspect te programs menu is jerky as the system must reload icons/data as items come into view - i beleive this is a caching (or lack of) issue.
the touchscren takes up a lot of cpu and as far as i can tell it doesnt matter what program has focus. touching the screen and moving my finger around produces around 50% cpu usage with both touchflo turned on and off (via the settings icon).
Click to expand...
Click to collapse
That's what I meant.
Buster
Well, i was here from the beginning. I didn't start the petition, but i posted it and asked for a sticky. I was one of the first few that posted about the lack of 3D. I'm very angry about my slow crappy Kaiser. But...
A BIG BUT:
- The "drivers" would NOT solve the slow video we see in TCPMP, since TCPMP decompresses in software. And any release of CorePlayer has the same performance. Maybe one released after the "drivers" are installed would be better.
- The "drivers" would NOT score higher in SPB benchmark.
We don't actually need "drivers". We need a build of WM6 (WM6.1) which is using a better SDK (libraries) from Qualcomm.
This is what i think needs fixing:
- Accurate VSync - so we don't get tearing anymore - this may also solve some slow programs.
- Better implemented sound library - i can't believe nobody complained about the sound - which is the worst, ever, in the whole world, in the universe. It sound like an old radio. A broken old radio. A broken old radio in a Faraday cage tuned to the wrong frequency...
BTW: the 4.3k score on graphics that the Kaiser got, and any other graphic benchmark is VERY VERY FAKE - they say 40+ FPS in some test, but i see 5 FPS on my screen (trust me, i know, i'm a render programmer in the game industry, i have an eye for these). What is actually happening is that the program says: draw this on the screen, and the hardware says "done" about 400 times a second, and it actually didn't render anything - this is what i mean by a good VSync.
I say this again - if we had 100% working drivers on our Kaiser right now, and you try them with TCPMP -> no difference, trust me. If you run Quake for PPC -> no difference, again. You would probably never know you had HW acceleration. The 2D HW part would be noticed in the Windows GUI (maybe) and in some programs (very few - those that use DirectDraw, and use it correctly)
Maybe we should try asking for what i said - no tearing, better sound, and maybe we'd get it.
Please, please don't post if you don't understand what i'm saying. This is for the big boys
agreed many of the ports of old 3d games like duke3d, doom1-2 quake1-3 .....
would most likely never benefit from a real driver as they are old games which
dident even benefit from 3d cards in pcs
so thinking that a driver will make anything faster is likely to cause tears
plus the ati powers of the kaiser and others is really not much of a 3d powerhouse like the geforce counterpart it does add some 2d speed up but thats about it
which is prob why a money aware company like qualcomm would bother to pay ati
the pretty small fee for their license
but at the end of the day htc are cheapskates
I understand your points and believe that everything you said is true. (Specially about the video drivers not solving the slow video problem).
However I don't see any problems with the audio on the Kaiser (at least on mine).
But yes, I also say that we need a better OS implementation for the Qualcomm chip.
Should we start a new (and proven ineffective) petition to HTC?
Cheers!
RayanMX
what borthers me is that htc seem to be happy enough to be the biggest wm device maker rather then really making an efford to compeat with iphone they seem to sleep on the bed of roses that iphone not being that available outside of us and not being 3g or having sd interface
kinda sad imho :S
Oh, and the funny part is that if they would have fixed the tearing and the DirectDraw bug before releasing it, nobody would have cared about the 3D HW not being used. Well, maybe me, omikr0n, and ten other guys would have cared, but it would have been forgotten in a few weeks.
The 2D DirectDraw was noticed only because TCPMP and CorePlayer have the option to use DDraw. And it could have been fixed - CorePlayer devs found a way around it.
In the end this is just a rushed device, using a cheap (and slow) platform - 400Mhz means nothing, it behaves like a 300Mhz Intel or 240Mhz TI OMAP - not a fact, just an analogy.
Just have one comment about the sound...
did you try the sound using any stereo speakers other than the mono speaker on the device itself? it is actually one of the finest and cleanest audio output i've heard for a while, i compared to ipod and tilt's sound was MUCH better
RPG0 said:
This is what i think needs fixing:
- Accurate VSync - so we don't get tearing anymore - this may also solve some slow programs.
- Better implemented sound library - i can't believe nobody complained about the sound - which is the worst, ever, in the whole world, in the universe. It sound like an old radio. A broken old radio. A broken old radio in a Faraday cage tuned to the wrong frequency...
BTW: the 4.3k score on graphics that the Kaiser got, and any other graphic benchmark is VERY VERY FAKE - they say 40+ FPS in some test, but i see 5 FPS on my screen (trust me, i know, i'm a render programmer in the game industry, i have an eye for these). What is actually happening is that the program says: draw this on the screen, and the hardware says "done" about 400 times a second, and it actually didn't render anything - this is what i mean by a good VSync.
Click to expand...
Click to collapse
Being a developer for such a long time, I feel you.
We should release our own benchmark program that we know won't get nop'ed out by some other timing code if we can't get to the vsync register.
The WM default midi soundbank is still crap as well as playback. My SE T610, and all my Palm Pilots playback midi with much more clarity. I know it's not the hardware because the alternative GSPlayer+ MIDI player plays the same samples just fine.
What can be learnt from the Apple II days is to just vote with the wallet. Fighting the hardware maker is wasted time and effort. Only complaint that gets their attention is a walking wallet.
edit: you know, we used to rawbuffer most of our graphics on the same resolution screen (320x240) on a vastly inferior CPU. No reason we can't try to do the same on the Kaiser with a super ARMv6 asm optimized library. We just need to shut up the OS from stealing so many cycles.
Of course I'm only thinking of 2D gaming without video decoding, and only MIDI music since those are the least CPU intensive.
ahussam said:
Just have one comment about the sound...
did you try the sound using any stereo speakers other than the mono speaker on the device itself? it is actually one of the finest and cleanest audio output i've heard for a while, i compared to ipod and tilt's sound was MUCH better
Click to expand...
Click to collapse
+1
I forgot I had an iPod since I got my Tilt. With an 8gb SD who needs one?
How do you come to the conclusion that drivers wouldn't help DDraw applications like CorePlayer and such?
Devices with proper drivers seem to work just fine with DirectDraw and they are able to create a proper HW overlay etc.
Granted it would not solve decoding of video, that's given. But it could/would/should surely speed up the actual rendering.
Writing to the dedicated video RAM instead of creating a framebuffer in normal system RAM should be faster. Hardware overlay should be faster than just using the standard rendering paths etc.
As for games: of course they won't be sped up unless the actual game supports D3D or OGL. Most games don't (even "fancy" 3d ones) but some do, such as COD.
Also, a proper DDI driver can and will speed up 2D rendering in general. Doing simple stuff like rendering just a menu is WAY too slow right now and that's unrelated to vsync. (There's certainly a world of difference between lacking the smootheness and tearing "freeness" of proper vsync and just performance in general, it shouldn't take a full second to draw a simple screen in WM if no other operations are active.)
As for sound I did have those problems but as of the latest 1.65.14.06 radio my audio is pretty much top notch. Sounds just as good as my ipod or my creative zen players and a whole lot better than the integrated soundcard of my laptop (realtek hd audio).
That's both during calls but especially when listening to music.
Of course with the bundled headphones or even with HTCs "high end" headphones it all sounds like crap. With a proper set of of in ear plugs (I've a "cheap" Shure set and a more expensive Sony one and they both sound simply awesome.)
Actually I really like using it as an audio player as it supports WMA Lossless (undocumented feature of Windows Mobile 6), few devices.
For whatever reason though poorly compressed songs sound much worse on this device compared to MP3-players in general.
If it's because the codec is poor or if it's so great that it makes smaller variances noticable is hard to say (I'd go for poor codec) but it's certainly not due to "poor sound".
Thats my $0.2
RPG0 said:
- The "drivers" would NOT solve the slow video we see in TCPMP, since TCPMP decompresses in software. And any release of CorePlayer has the same performance. Maybe one released after the "drivers" are installed would be better.
Click to expand...
Click to collapse
I have to disagree here...
The current routines being used for DirectDraw are slow and inefficient. Probably using very slow CPU calls. It's for sure a software CPU routine drawing the pixels.
Anyone who has done raw hardware video programming can attest if you popped an interrupt to draw one pixel on the screen vs using DMA access the difference is night and day. The interrupt method chews up CPU cycles drawing the pixels ont he screen vs the DMA method which doesn't waste CPU cycles and is far more efficient.
Pointing directdraw to use hooks into the GPU and or DMA access to a hardware frame buffer would improve things significantly (night and day). You can easily see this by playing a video on an old PPC6700 which has proper direct draw routine implemented. The difference is HUGE factor of 10 I'd say.
The slow video rendering has nothing to do with the CPU doing the video decompression. It has to do with the directdraw routines not being implemented efficiently and the CPU wasting it's cycles drawing pixels on the screen. You can see "tearing" because you can SEE the video refreshing the screen out of the vsync due to the slow directdraw routines that exist. The the CPU should be concentrating on decoding video not wasting cycles drawing the video. The directdraw routine should be writing to a framebuffer using DMA or some similar method.
This is what's going on (high level lame explantion). Pretend the below are mappings.
Method #1
DirectDraw -> IntXX (video interrupt)
or
Method #2
DirectDraw -> DMA (direct memory to the video card)
Using method #1 it will cost you CPU cycles just to draw the pixels. So not only does your device need to concentrate on decoding the video it also needs to waste CPU cycles drawing pixels on the screen one by one. And the larger the screen area your painting, the more CPU it costs you. You can even experience this on a device like the Mogul (6800); you can get faster frame rates when you draw less pixels.
Using method #2 drawing video costs your CPU basically no overhead and it can spend it cycles decoding the video. It will use DMA to write to a video frame buffer instead of making CPU calls to do it.
These are just examples, but this how it's broken from my hardware programming experience.
The post above mine is also a good reference.
I stand by my statement, that having a good DDraw implementation will not help. In theory, you're right, but on other devices (Htc Prophet aka Qtek S200 and HTC Touch) there was no difference between Raw framebuffer or GDI and DDraw. So real-life scenarios tend to prove me right.
The only reason things could speed up is the hardware conversion between YUV and RGB, but for a 320x240 frame, that takes very little time to do in software, and for some codecs, the conversion is not necessary. I can explain what YUV means, and why it's used in video/image compression if anyone is interested, but you can google youself.
About the sound part, maybe i have an old radio ROM, maybe i have a defective device or maybe it's just my configuration.
EDIT: Don't forget that even when using HW overlay, you STILL have to fill the surface with pixels (the pixels you just decoded), so you have to write 320x240 somewhere (with DDraw you write in the memory area you get with Lock(), in Raw framebuffer you write directly in an area that is drawn afterwards). If you ignore the YUV->RGB conversion, you gain NOTHING with DDraw.
As i said, i'm a game render programmer, and i did some image/video compression/decompression in my time, so you can get technical, I'll understand.
so !!
hi fpgo,so how are sony/ericsson getting round video prob on X1 xperia ? I guess their not going to market with a half crippled device, unlike htc,from what I can make out x1 is only a tweaked kaiser,so could we not just back engineer their solution ?
greatly disapointed with kaiser all round.if id known se version was due,id have waited to upgrade,still prefer my p910i,just no 3g.
tleaf100 said:
hi fpgo,so how are sony/ericsson getting round video prob on X1 xperia ? I guess their not going to market with a half crippled device, unlike htc,from what I can make out x1 is only a tweaked kaiser,so could we not just back engineer their solution ?
greatly disapointed with kaiser all round.if id known se version was due,id have waited to upgrade,still prefer my p910i,just no 3g.
Click to expand...
Click to collapse
If you watch the CNET video from Bonnie Cha on the X1, you'll see it's actually pretty slow in the rendering as well, so forget that.
Now back to the experts.
X1
sorry,not seen video,will go and have a look.
was only an idea...
will leave to you "experts" ....
RPG0 said:
I stand by my statement, that having a good DDraw implementation will not help. In theory, you're right, but on other devices (Htc Prophet aka Qtek S200 and HTC Touch) there was no difference between Raw framebuffer or GDI and DDraw. So real-life scenarios tend to prove me right.
The only reason things could speed up is the hardware conversion between YUV and RGB, but for a 320x240 frame, that takes very little time to do in software, and for some codecs, the conversion is not necessary. I can explain what YUV means, and why it's used in video/image compression if anyone is interested, but you can google youself.
About the sound part, maybe i have an old radio ROM, maybe i have a defective device or maybe it's just my configuration.
EDIT: Don't forget that even when using HW overlay, you STILL have to fill the surface with pixels (the pixels you just decoded), so you have to write 320x240 somewhere (with DDraw you write in the memory area you get with Lock(), in Raw framebuffer you write directly in an area that is drawn afterwards). If you ignore the YUV->RGB conversion, you gain NOTHING with DDraw.
As i said, i'm a game render programmer, and i did some image/video compression/decompression in my time, so you can get technical, I'll understand.
Click to expand...
Click to collapse
Well, YUV overlay support would be very nice, but I doubt we will see it working on kaiser (does Imageon even supports it?). But.. Working DDraw accel. would still help - for example when doing soft yuv->rgb conversion and double buffering result - you would definitively get better results if Kaiser have had hw accelerated bitblt (or at least less tearing).
*** Massive Brain Overload*** "Apparently these people are speaking a strange dialect I've never heard before" -Harold & Kumar Escape from Montanamo Bay
RPG0 said:
...
- Better implemented sound library - i can't believe nobody complained about the sound - which is the worst, ever, in the whole world, in the universe. It sound like an old radio. A broken old radio. A broken old radio in a Faraday cage tuned to the wrong frequency...
Click to expand...
Click to collapse
LOL! And that will be the funniest thing I hear all day. And I just woke up.
Oh, and since HTC said they are releasing a new ROM which fixes the speed of the device, but does not bring HW accel (drivers), i think my problems will be over.
new rom
ahh,and when is this magical fix for kaiser meant to be released to public ?
my kaiser has become 3g /hsdpa usb modem,and gone back to p910i for everyday use,kaiser too fussy/slow/clunky for busy gardener,keeping fingers crossed about s/e "paris".
Just a shameless bump
Hey guys, need a bit of help...
Been using the Z a few days now, and I'm having 2 issues...
WiFi and Bluetooth won't work together at the same time, one knocks the other off whenever I'm browsing and listening to music on my Bluetooth stereo... In the ratio of about 5:1 for WiFi:Bluetooth like...
That's one issue that's a little annoying.
Another is that video playback over WiFi is broken... If I load up a video on the YouTube app, depending on video length, the video normally freezes around the 40 second mark. If I load a video up in my browser, more of the video will load, but never the full video, could freeze 3 minutes in, 5 seconds in, but never fails to freeze.
I've reverted to stock YouTube app, cleared cache, didn't solve a sausage.
I haven't gotten to the end of a single video since I bought the device.
EDIT: Above issue is most likelyan android wide YouTube issue, if the comments on Play are anything to go by.
And that's on top of the Bluetooth/WiFi clashing that I mentioned above.
Not what I expect from a quad core device with 2GB ram like! Any ideas? Faulty handset? Factory reset? Return the handset? I've never rooted or used custom firmware ;so don't really know how to go about it, open to any suggestions to get the best out of the hardware...
Thanks in advance guys.
WiFi/Bluetooth issue
Seems the YouTube issue is an android wide issue, sorry for bringing it up.
Just leaves the Bluetooth/WiFi clashing issue where they keep knocking each other off while they're both being used.