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?
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
hi,
this question because i really think the vga screen is very good for some issues but in tomtom we really need big glasses to see correctly poi for exemple...
and also maybe we can set up the diamond as Qvga for native mode ? like that performance will be better maybe ?
People in xda say than they hav lag in tomtom, maybe it's because of using a lot a cpu for tomtom (tomtom i think is not optimised for diamond) in vga mode because i also encounter lag with tomtom and no lag with igo 8 who is very "luquid"
sorry for my bad english
lomiz from France
Usually, lcd panels "don't like" another resolution, then the native.
The "native" screen size of the diamond is 640x480 and this will never change - unless you replace the screen. As mentioned above, if you wanted the screen to work in a lower resolution and you found a way to do this, you would probably use up extra processing power (and so more battery) "down scaling" the picture. This would almost certainly mean things would be slower.
That said, as I understand it, we do have custom graphics chips in the diamond and if they have driver support (almost all phones with the Nvidea chipset don't have driver support) then it maybe possible i suppose? Again, it would push things out of scale though and probably still use more power in the long run as you are asking the chips to work harder - even though its a lower res.
Monty Burns said:
The "native" screen size of the diamond is 640x480 and this will never change - unless you replace the screen. As mentioned above, if you wanted the screen to work in a lower resolution and you found a way to do this, you would probably use up extra processing power (and so more battery) "down scaling" the picture. This would almost certainly mean things would be slower.
That said, as I understand it, we do have custom graphics chips in the diamond and if they have driver support (almost all phones with the Nvidea chipset don't have driver support) then it maybe possible i suppose? Again, it would push things out of scale though and probably still use more power in the long run as you are asking the chips to work harder - even though its a lower res.
Click to expand...
Click to collapse
As VGA is an integer multiple of VGA resolution, there should be no GPU time problem for this (it lites 4 pixels instead of 1). But the GPS lag seems to have nothing to do with graphic processing. If you try to simulate a trip, you'll see that there's no screen lag. And lag problem on diamond seems to be more a GPS chip problem : your position seems not to be updated very often, that's why TTT or any other GPS app lag : it's jumping from one position to another, according to GPS chip informations.
(sorry for my poor english... i'm french)
Araldwenn said:
As VGA is an integer multiple of VGA resolution, there should be no GPU time problem for this (it lites 4 pixels instead of 1). ....
Click to expand...
Click to collapse
Exactly. BUT Its not a case of just "knowing" that 1 pixel = 4, it would have to calculate that for EVERY pixel, for EVERY refresh. Obviously, its not a huge demand, our TV's do it all the time but it will add extra work load which will take time and battery.
Ok so Manila is a huge ram monster I found that a few registry tweaks dose the trick for the dreaded core player lagging XD
First: ResProxy
HKLM\Software\HTC\ResProxy
"ShareMemSize"
Change this value to zero
http://forum.ppcgeeks.com/showthread.php?t=85716&page=5
“ResProxy is HTC's method of "Pre-Caching" your applications on the phone, therefore loading times are faster when opening, etc. It just allocates a chunk of your memory for this feature. Problem is, after about a day of not soft-resetting your phone, your idling at 90% or so.
Changing it to 0 will set this as DYNAMIC. So instead of a bunch of pre-set apps being precached IMMEDIATELY, it does it dynamically. It will only raise the memory for the apps that you are currently using, etc.
Keep in mind, changing this REG does not affect speed in terms of opening applications,etc. Performance stays identical.
You will not notice IMMEDIATELY that this tweak has worked. You will notice later in the way when you notice your device won't idle higher than 65-70% usage anymore, and won't even get as high as 90% unless your running mad software on it lol.
Enjoy! “
Second: PushInternet
http://forum.xda-developers.com/showthread.php?t=532948
HKLM\Software\HTC\PushInternet\Enable => change to 0
Note: with both of them turned on the core player benchmark was of 48.8%
With just the Resproxy off it was at 58.8%
And with both off it got up to 115%
Scratch that, it didn’t help
It only worked just once and then went back to lagging
I'm a long time user of Core Player on several devices with Manilla & it's never been a problem for video playback for me. If video playback is your issue, rip better video files. I use .avi files sized from 550mb to 800mb.
If I turn off Sense UI, I can play videos fine using QTv display on high quality with zoom and dither off
No ghosting or anything...
With Sense UI on, I have to down to medium quality videos to avoid ghosting. So I usually turn off Sense if I'm going to watch something long...
Good effort. Since it didn't really work out, I'm going to put this thread out of it's young misery.