Database Develop

Delay by touchscreen, not only by missing video drivers

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

[Q] Light sensor values

Can someone try out the app androsensor and check what values the light sensor reports?
Mine only reports 5 values:
0, 10, 100, 1000 and 10000.
0 - total darkness
10000 - right next up to a light
It should report a much broader range of values. This should also cause worse auto-brightness, since the device only has five light values on which to chose, instead of a few thousand.
I suspect this is a software issue and could be fixable.
Edit:
Running Rocket ROM v11.

honf said:
Can someone try out the app androsensor and check what values the light sensor reports?
Mine only reports 5 values:
0, 10, 100, 1000 and 10000.
0 - total darkness
10000 - right next up to a light
It should report a much broader range of values. This should also cause worse brightness, since the device only sees five light values instead of a few thousand.
I suspect this is a software issue and could be fixable.
Edit:
Running Rocket ROM v11.
Click to expand...
Click to collapse
Tested it . Only got 3 values 10,100 ( at 10 cm of a lamp ) and 1000 right at the lamp. Never even got 10000.
So you probably found something , but how fix it ?

It appears to be a common "feature" across several devices. Though some report different values, they are generally kept to within six to seven values.
For information on other devices, check out the submition on reddit

GPS remarkable observation

Guys,
I spent 2 weeks of holidays (my wife almost left me for that) mostly trying to find out why GPS performance on my P970 is so poor, losing satellites fixes every so often and sometimes no fix at all although 'seeing' satellites. I did not find a 'real' solution, even after tests on both mostly Huexxx 7 and lately boype's 0909, too.
Best results now on boype's 0909 CM7 but with adapted gps.conf and gps_brcm_conf.xml. Nevertheless, the result is still disappointing, far away from satisfying.
However, during all these checks, I found that satellite's receiption is depending on the way I hold the device in my hands, at least on MY device. Whenever I hold a finger on the top left of the chassis (just above the location where the GPS chip is located, see pictures), then receiption improves by 0 up to 14 db (!!!).
Also the number of 'seen' and 'used' birds increases from 6 to 10 easily!!! However, the fix did not become more stable through that.
Pls check on your devices if you can verify the same behaviour.
If so, what could be the reason (i do not put any pressure on the device)? And is there anything that we can do to make this improvement permanent, i.e. put a piece of 'aluminium foil' between the back lid and the device or something similiar?
Let me know your remarks, guys.

No problem at all. Riding on the tram right now. Fix on 12 in few seconds. Sure it's not because of your position? And 6 is enough to fix the position.

@eighty-four
I appreciate your info, and you are surely right it is depending on my position. My question was a different one though: Do you observe the same reaction as soon as you put the finger on top of the device; i.e. increase of signal strength?
BTW You attached an impressive picture, would like to aks you are you still on AOKP beta 1.1 ICS 4.0.4 and how do your files gps.conf and gps_brcm_conf.xml look like? Can you share them?

AOKP 1.1, no any GPS fixes
Hard to say about reaction while on move. But didn't noticed any noticeable changes.
Can't check now - I'm in home.

I've been using Marvel v9 since released, with the GPS "Tweaks" installed too.
I'm getting GPS signal, sometimes really fast, some others i need to wait for a couple of minutes (maximum 3 minutes).
There are certain times though, that it doesnt lock no matter what, just like in your situation. It manages to find many sattelites (7+) with an average decent signal strength but it refuses to get a gps fix location.
I believe it has to do with the temperature of the chip (i couldnt get easy GPS fix at winter) because now that summer passed by and used my GPS a lot, i had no issues... might be the clouds, might be the stars alignment and zodiacs ... i really dont know.
It's not that accurate and fast though for city driving. Some turns are being announced way too late (Sygic Aura) and the error treshold is about 10meters mostly, rarely goes down at 5meters.
I guess it's a chip manufacturing bull**** rather than a "case construction" or antenna problem.

@morx
I just wanted to check if others can verify better receiption when holding finger on top.
I agree it seems a hw or engineering defect, nevertheless I am trying to optimize the settings in order to compaensate at least partially.
Interesting you mention the temperature: In my research I came across a relationship between temperature and gps accuracy. Our (and any other gps chip) uses a oscillator hw module for precision timing. These oscillators' accuracies depend on the temperature and are measuered in PPM. There is also a setting in the gps_brcm_conf.xml that refers to this, it is "FrqPlan". The usual value in CM7 is "FRQ_PLAN_26MHZ_2PPM_26MHZ_300PPB". However, other values do also work, like "FRQ_PLAN_26MHZ_2PPM_26MHZ_100PPB".
You can check details in THIS post.
Would be interesting to determine if different values lead to better results.

I had no clue that chip temperature had a side effect on GPS fix !!
When i was writing my concern about that, i was feeling stupid until i saw your redirection to that post...
hmmm there are many factors which can be put on the table about optimization and troubleshooting.
Later on, i'll give a try keeping the cellphone with both hands, different angles, one handed on top/bottom etc...

Interesting thoughts.
I'm on CM10 nightly and always had blazing fast fixes until yesterday. I activated GPS in my car and after 3 minutes it fixed (in Osmand), after some more minutes the fix got currently lost.
Due to my big custom 3500 mAh battery I couldn't place my phone in the cradle therefore I simply laid it onto my dashboard. Maybe because of this the signals were harder to receive.
I will switch back to the normal battery today and try to test your variant.
Sent from my LG-P970 using xda app-developers app

Wondering if burn-in might be caused by elevated temperature from added case.

https://drive.google.com/file/d/1UO84SCeykrD6Ecb9p3yWfoUe4KN2pJs2Eg/view
Above you can see detectable (under close scrutiny, ideal conditions) burn-in of my Nexus 6 screen after the following usage:
Only 8 weeks since I bought the phone
I'm reasonably sure that this was not present when I got the device because:
1 - it was "new" from Amazon in factory sealed box (although at a bargain price $299 for 64gb which makes me wonder slightly);
2 - inspected it pretty careully when I was reading about burn in shortly after I got my device;​
My screen on time on a typical day is probably 2-5 hours per day over that 8 weeks. (although probably 5-6 hours per day during the very first week!)
Brightness is always in auto with the slider in the middle. And I don't spend a lot of time outside with my screen on.
You can see that's pretty mild usage for a relatively short time. And yet many others are reporting they absolutely can't detect anything whatsoever even after a year of use. . I'm led to believe I'm an outlier.
So what is it that might make me more susceptible than the next guy?
The "easy" answer is device quality. And it might be the right answer, but what if there's something else.
I thought about what it is in my usage (which seems relatively mild) that might possibly cause this.
Then I realized the one thing that struck me odd about this phone. I noticed the screen is warm to my fingers if I use it while charging. I didn't meausre that temperature, but I did download GSAM about a month in and and set a battery temperature alarm at 110F. If I do mild surfing while charging, battery temperature gets up to 110F within a few minutes. I don't let it go above that now, and the screen feels relatively cool compared to how hot I used to let it get. So I'm going to guess that my battery temperature used to routinely get to 115 or 120F while I was using my phone while charging. And although they're not equal, when battery gets hot screen gets hot (again I could feel the heat).
Would heat affect amoled deterioration? We wouldn't think that at first because we normally associate the deterioration with simply being energized brightly over time. But what about being energized causes that deterioration. What if it's the localized heat at the pixel from that brightly energized pixel that causes the damage. In that case, anything else which makes the phone/screen run hotter overall will tend to enhance that local damage mechanism also.
Does my phone run hotter than average? I'm not sure, but since day 1 I've been using this funky case Uniform Supcase Beetle Hybrid Pro.. It's built like an otterbox.... thick and rugged. Up to 1/4" inch thick and surrounds the phone on back, all sides, and even wraps around to cover the front bezel. Imagine that wrapping is an insulator (like a blanket), it helps to keep the heat inside so the phone underneath the blankets is hotter than it otherwise would be.
Is that case why I'm different? I dunno, all I've got is one phone as a data point and a scenario that seems plausible to me.
I'm interested to know if any others have associated elevated temperatures or a thick case with enhanced susceptibility to burn-in . Or if you believe it may be related.
By the way, I have to add my perspective this is a minor and managable thing. I still love this phone. I'm just curious about why...
There are of course many threads on subject of N6 burn-in. The biggest one here:
http://forum.xda-developers.com/nexus-6/general/burn-t2955765

electricpete1 said:
https://drive.google.com/file/d/1UO84SCeykrD6Ecb9p3yWfoUe4KN2pJs2Eg/view
Above you can see detectable (under close scrutiny, ideal conditions) burn-in of my Nexus 6 screen after the following usage:
Only 8 weeks since I bought the phone
I'm reasonably sure that this was not present when I got the device because:
1 - it was "new" from Amazon in factory sealed box (although at a bargain price $299 for 64gb which makes me wonder slightly);
2 - inspected it pretty careully when I was reading about burn in shortly after I got my device;​
My screen on time on a typical day is probably 2-5 hours per day over that 8 weeks. (although probably 5-6 hours per day during the very first week!)
Brightness is always in auto with the slider in the middle. And I don't spend a lot of time outside with my screen on.
You can see that's pretty mild usage for a relatively short time. And yet many others are reporting they absolutely can't detect anything whatsoever even after a year of use. . I'm led to believe I'm an outlier.
So what is it that might make me more susceptible than the next guy?
The "easy" answer is device quality. And it might be the right answer, but what if there's something else.
I thought about what it is in my usage (which seems relatively mild) that might possibly cause this.
Then I realized the one thing that struck me odd about this phone. I noticed the screen is warm to my fingers if I use it while charging. I didn't meausre that temperature, but I did download GSAM about a month in and and set a battery temperature alarm at 110F. If I do mild surfing while charging, battery temperature gets up to 110F within a few minutes. I don't let it go above that now, and the screen feels relatively cool compared to how hot I used to let it get. So I'm going to guess that my battery temperature used to routinely get to 115 or 120F while I was using my phone while charging. And although they're not equal, when battery gets hot screen gets hot (again I could feel the heat).
Would heat affect amoled deterioration? We wouldn't think that at first because we normally associate the deterioration with simply being energized brightly over time. But what about being energized causes that deterioration. What if it's the localized heat at the pixel from that brightly energized pixel that causes the damage. In that case, anything else which makes the phone/screen run hotter overall will tend to enhance that local damage mechanism also.
Does my phone run hotter than average? I'm not sure, but since day 1 I've been using this funky case Uniform Supcase Beetle Hybrid Pro.. It's built like an otterbox.... thick and rugged. Up to 1/4" inch thick and surrounds the phone on back, all sides, and even wraps around to cover the front bezel. Imagine that wrapping is an insulator (like a blanket), it helps to keep the heat inside so the phone underneath the blankets is hotter than it otherwise would be.
Is that case why I'm different? I dunno, all I've got is one phone as a data point and a scenario that seems plausible to me.
I'm interested to know if any others have associated elevated temperatures or a thick case with enhanced susceptibility to burn-in . Or if you believe it may be related.
By the way, I have to add my perspective this is a minor and managable thing. I still love this phone. I'm just curious about why...
There are of course many threads on subject of N6 burn-in. The biggest one here:
http://forum.xda-developers.com/nexus-6/general/burn-t2955765
Click to expand...
Click to collapse
I can notice burn in on mine (I use no case at all) but its very mild and a "burn-in fixer" like the black and white rolling lines from "Display Tester" makes it go away if ever I'm that bored to do so. Also I only ever notice it on a grey background which honestly is rare to appear where the status and button bars are. On the terms of battery temp I really have to get something going to hit >105F for instance downloading videos using multiple streams to make it go faster which requires stitching the video back together at the end which basically pegs the cpu. General browsing reading some news stories etc stays ~85-90F. Differences in temps between phone for this one in particular can swing wildly due to there being upwards of 17 different CPU "bins" (compared to something like 3-4 on the Nexus 5) with each bin being a 10mV shift in the voltage table for the CPU meaning on CPU can have a 300mhz at 810mV (bin0) and another could have it at 650mV (bin16). For reference mine is a Bin 12 or 690mV on the 300mhz and 1110mV on 2.7ghz.

Both of my devices (had the old one for about 2 months, this guy for about 1) both show burn-in similar to yours already. First was caseless, this one I run with a case. I think that burn-in is just a very widespread issue with this panel and the people claiming to not have any simply don't notice it. Maybe I got 2 bad devices fresh from amazon but, I think that's just how it is. Good news is it really doesn't bother me and I can't see it without a gray background.

electricpete1 said:
https://drive.google.com/file/d/1UO84SCeykrD6Ecb9p3yWfoUe4KN2pJs2Eg/view
Above you can see detectable (under close scrutiny, ideal conditions) burn-in of my Nexus 6 screen after the following usage:
Only 8 weeks since I bought the phone
I'm reasonably sure that this was not present when I got the device because:
1 - it was "new" from Amazon in factory sealed box (although at a bargain price $299 for 64gb which makes me wonder slightly);
2 - inspected it pretty careully when I was reading about burn in shortly after I got my device;​
My screen on time on a typical day is probably 2-5 hours per day over that 8 weeks. (although probably 5-6 hours per day during the very first week!)
Brightness is always in auto with the slider in the middle. And I don't spend a lot of time outside with my screen on.
Click to expand...
Click to collapse
That's an interesting theory.
I'm one of those who have absolutely NO detectable burn in, either permanent or latent. I also run a thick case -- Ballistic Maxx.... but... I have (used to, but don't any more) used it very hot. In particular google maps nav used to really make a lot of heat, enough that you could REALLY feel it on the screen, and even through the case. Somewhere along the lines, something changed enough in (firmware? OS? gmaps?) that this no longer gets it to heat up appreciably. Aside from that, I've *never* used it while charging -- kind of difficult to do so with wireless charging. Auto-brightness with the slider at about 1/3. I've owned it for a year now.
---------- Post added at 08:49 PM ---------- Previous post was at 08:39 PM ----------
StykerB said:
I can notice burn in on mine (I use no case at all) but its very mild and a "burn-in fixer" like the black and white rolling lines from "Display Tester" makes it go away if ever I'm that bored to do so. Also I only ever notice it on a grey background which honestly is rare to appear where the status and button bars are. On the terms of battery temp I really have to get something going to hit >105F for instance downloading videos using multiple streams to make it go faster which requires stitching the video back together at the end which basically pegs the cpu. General browsing reading some news stories etc stays ~85-90F. Differences in temps between phone for this one in particular can swing wildly due to there being upwards of 17 different CPU "bins" (compared to something like 3-4 on the Nexus 5) with each bin being a 10mV shift in the voltage table for the CPU meaning on CPU can have a 300mhz at 810mV (bin0) and another could have it at 650mV (bin16). For reference mine is a Bin 12 or 690mV on the 300mhz and 1110mV on 2.7ghz.
Click to expand...
Click to collapse
That operation *should not* be especially hard on the CPU. Its actually a fairly trivial task. Might be that your software is doing something stupid, like keeping all the different pieces separate until the end when it copies them all in sequence into a target file.
You might want to look into better downloader software. The *correct* way to perform this kind of a job, is to allocate the file in advance, and have each stream write to its correct offset in parallel. No final copy.
You might also save a heap of work if you get rid of userdata crypto. Big problem with the crypto on these when doing that kind of glue-job, is that it will be running decrypt on all the different pieces, and simultaneously running encrypt on the target file.

That operation *should not* be especially hard on the CPU. Its actually a fairly trivial task. Might be that your software is doing something stupid, like keeping all the different pieces separate until the end when it copies them all in sequence into a target file.
You might want to look into better downloader software. The *correct* way to perform this kind of a job, is to allocate the file in advance, and have each stream write to its correct offset in parallel. No final copy.
You might also save a heap of work if you get rid of userdata crypto. Big problem with the crypto on these when doing that kind of glue-job, is that it will be running decrypt on all the different pieces, and simultaneously running encrypt on the target file.
Click to expand...
Click to collapse
Well for 360p, 144p, and 720p which are the resolutions you can natively download from youtube as an MP4 do function this way (which if you download these resolutions the software just takes ~5 seconds to finalize the file after downloading). However since youtube is exactly keen on people downloading videos w/o Red (which I do have but I like having 1080p and/or 60fps for gaming style videos which Red does not allow for unfortunately). So those non-standard resolutions have to be downloaded in their little 4096 kb chunks with separate video and audio streams as if it were streaming it from the website itself and stitched together using an actual encoder. A 1080p60 video can put a sizable load ~50-100% i5 5200u laptop processor (depending on the complexity of the scene) while realtime streaming which arguably has more raw power than a N6 (part of the reason youtube still streams AVC codec to android). Now with the phone not having to actually render the video which VP9 codec isn't supported fully either device's GPU so a chunk of the load on the laptop would be rendering. The phone being able to finalize a 1080p60 30 minute video in ~1 minute is why the CPU is 100% while doing so and that just tells me it's using all the power it can to accomplish the task in parallel utilizing all 4 cores.
As for using encryption I've disabled it in the past with varied results (mostly kernel differences) but since I'm sticking with the stock rom and using the monthly ota's I've just left it on to stop any potential accidental encryption which could theoretically lead to data loss and/or the hassle of unecrypting again. In addition to this I see absolutely no gain in speed on the video stitching process which considering it performs the task at a ~15-20 MB/s rate where the limits of the encrypted storage are 200MB/s read and 90 write for sequential reading which is what the encoder is using. Since android 5.1 when the kernel was updated to take advantage of qualcomm's encryption instructions which would otherwise go unused to the OS anyway, encryption doesn't affect this type of workload.
I know this is kinda outside the scope of this thread but I have done some reading on this kinda stuff when I was trying to learn why the app needed an external app when downloading those difference resolutions which most apps wouldn't even do outside of PC software.

StykerB said:
Well for 360p, 144p, and 720p which are the resolutions you can natively download from youtube as an MP4 do function this way (which if you download these resolutions the software just takes ~5 seconds to finalize the file after downloading). However since youtube is exactly keen on people downloading videos w/o Red (which I do have but I like having 1080p and/or 60fps for gaming style videos which Red does not allow for unfortunately). So those non-standard resolutions have to be downloaded in their little 4096 kb chunks with separate video and audio streams as if it were streaming it from the website itself and stitched together using an actual encoder. A 1080p60 video can put a sizable load ~50-100% i5 5200u laptop processor (depending on the complexity of the scene) while realtime streaming which arguably has more raw power than a N6 (part of the reason youtube still streams AVC codec to android). Now with the phone not having to actually render the video which VP9 codec isn't supported fully either device's GPU so a chunk of the load on the laptop would be rendering. The phone being able to finalize a 1080p60 30 minute video in ~1 minute is why the CPU is 100% while doing so and that just tells me it's using all the power it can to accomplish the task in parallel utilizing all 4 cores.
As for using encryption I've disabled it in the past with varied results (mostly kernel differences) but since I'm sticking with the stock rom and using the monthly ota's I've just left it on to stop any potential accidental encryption which could theoretically lead to data loss and/or the hassle of unecrypting again. In addition to this I see absolutely no gain in speed on the video stitching process which considering it performs the task at a ~15-20 MB/s rate where the limits of the encrypted storage are 200MB/s read and 90 write for sequential reading which is what the encoder is using. Since android 5.1 when the kernel was updated to take advantage of qualcomm's encryption instructions which would otherwise go unused to the OS anyway, encryption doesn't affect this type of workload.
I know this is kinda outside the scope of this thread but I have done some reading on this kinda stuff when I was trying to learn why the app needed an external app when downloading those difference resolutions which most apps wouldn't even do outside of PC software.
Click to expand...
Click to collapse
I can't even bother to read that since (a) it is out of scope, (b) is from an end-user point of view, and (c) doesn't actually address anything related to what I've explained to you.

Question Picture in Picture, Split Screen etc - Refresh Rate drops to 60Hz (EXYNOS)

Hi there, I'd not noticed this before the Android 12 update, but refresh rate appears to drop from 120Hz to 60Hz when using Picture in Picture or Split Screen views. Can anyone else reproduce this please?
You can confirm this by going into developer mode and toggling to always display the refresh rate.

Try a factory reset if you haven't already and it was a OTA upgrade...

I'd rather see if others can reproduce this first - would have thought it's a simple enough thing to test and post your results here, thanks!

Hi SSJ100, I just tested this to confirm for you, it does drop to 60hz immediately and I cannot prompt it to 120hz until I return to full screen view

Further testing, if i have video running in the background, Amazon, netflix or YouTube it stays at 120 with windowed mode on

DS1000RR said:
Hi SSJ100, I just tested this to confirm for you, it does drop to 60hz immediately and I cannot prompt it to 120hz until I return to full screen view
Click to expand...
Click to collapse
Thanks for checking! Again though, I'm quite amazed (okay, maybe not quite the word hehe) at how no one has reported this issue in this forum (and at least one other "major" forum). If they have, please excuse my ignorance and I'd appreciate a link to the thread.
I can also confirm that this issue persists even after updating to the so-called bug fixing patch "BUKG".

DS1000RR said:
Further testing, if i have video running in the background, Amazon, netflix or YouTube it stays at 120 with windowed mode on
Click to expand...
Click to collapse
Interesting how bugs like this manifest sometimes huh hehe. I first noticed this issue with Google Maps when I was navigating with it and switching to another app (which automatically forces Google Maps app to become picture in picture mode). Scrolling looks quite different and jittery - it's amazing how one gets used to 120Hz!

Have you tried the tiles app developed by a user on here? It can force refresh rates very easily and just requires an adb permission.....there was a thread the other day

ssj100 said:
Scrolling looks quite different and jittery - it's amazing how one gets used to 120Hz!
Click to expand...
Click to collapse
There is some black magic going on with these 120Hz panels. 60 Hz never seemed to be a problem before these high refresh rate displays started popping up. I remember smooth as butter 60Hz phones (both iphones and android). But now when i use a 120Hz panel at a 60Hz refresh rate, it feels like something inside the phone is in it's death throes, coughing and spluttering - the stutter is jarring! But if I use my wife's OnePlus 6 (which has a fixed 60Hz screen), it doesn't feel so bad. It's definitely not as smooth as 120Hz but the 60Hz on a 60Hz panel feels smoother than 60Hz on a 120Hz panel. Is it only me or has anyone else had a similar experience?

I have the same issue as well..so pissed..using latest BUKG

I'm on Android 11, One UI 3 still, and when my phone displays split screen apps the refresh rate drops from 120 down to 60.
This must be some battery saving feature, because If I toggle performance mode (processing speed) from the drop down quick menu, the fps shoots back up to 120 in split screen.
So an easy fix if you need 120 in split screen.

Gasman said:
I'm on Android 11, One UI 3 still, and when my phone displays split screen apps the refresh rate drops from 120 down to 60.
This must be some battery saving feature, because If I toggle performance mode (processing speed) from the drop down quick menu, the fps shoots back up to 120 in split screen.
So an easy fix if you need 120 in split screen.
Click to expand...
Click to collapse
Yes, that seems to "fix" it for split screen. However, it doesn't resolve picture in picture fps drop to 60Hz.

Hmm must be an Android 12 thing. I'm sat here typing this with YouTube playing pip and the screen is holding 120fps even with my finger removed from the screen.
I did try Android 12 when the public version was released, but didn't like it, so downgraded back to the last version of 11, with a clean wipe.

Ok something odd going off, my screen seems to be stuck at 120!
Forcing it back to 60 in display options, works. Putting it back to adaptive, keeps the screen at 120. Even on the lock screen, and AOD!
I might try a reboot.

Gasman said:
Ok something odd going off, my screen seems to be stuck at 120!
Forcing it back to 60 in display options, works. Putting it back to adaptive, keeps the screen at 120. Even on the lock screen, and AOD!
I might try a reboot.
Click to expand...
Click to collapse
If you're in low ambient light, screen at low brightness, panel will be locked at 120Hz even with adaptive selected. Move to bright area or increase screen brightness and check if you are able to get to 60Hz

Gasman said:
Hmm must be an Android 12 thing. I'm sat here typing this with YouTube playing pip and the screen is holding 120fps even with my finger removed from the screen.
I did try Android 12 when the public version was released, but didn't like it, so downgraded back to the last version of 11, with a clean wipe.
Click to expand...
Click to collapse
Yes, I've only noticed this issue since Android 12 with the picture-in-picture scenario. Hopefully Samsung fixes this soon.

Gasman said:
Ok something odd going off, my screen seems to be stuck at 120!
Forcing it back to 60 in display options, works. Putting it back to adaptive, keeps the screen at 120. Even on the lock screen, and AOD!
I might try a reboot.
Click to expand...
Click to collapse
Nothing odd there - as previous poster mentioned, it's always behaved that way when the ambient lighting is low enough. And yes, has always been that way for AOD too. I never understood why 120Hz is required particularly for that!

I think that after android 12, my unlock animation is rendered at 60hz because it is sometimes sluggish. Did a full factory reset and i have the last update. Do you guys experience the same? other than that the phone is perfectly smooth

Still the same issue with BULC December update. Somewhat disappointing, as you'd think this should be quite an easy fix.

Still same issue after BULG update with PIP. As a previous person has noted, split-screen mode appears to be auto-throttled to 60Hz by default, and the only way to change this so it remains at 120Hz is by toggling "High" or "Maximum" "Processing speed".