Related
I previously sorted out the locking up problems with help from you guys on here, and I'm sure that I have seen something about a battery indicator on screen when not using O2active but can't find it. Can someone post a link to the thread if it actually does exist or does the function not exist out of O2active?It's quite possible that I had a "moment" and imagined that I saw this of course - it's an age thing, hopefully!
Cheers. Alan
Why not load up the GPRS monitor program that the device come with and configure that to display Battery status on the screen - after its free, and a damn good utility if you use GPRS to track the cost - Mike
Or download Batti (just search for it - it's free)... I use it, and love it, for various reasons I won't bother to detail here
Thanks for that, I'll do a bit more digging. I don't use GPRS for monitoring (as far as I know) so I'll have a look at batti.
In. Done. What a handy little thing! Thanks again.
There's several, really... I like to classify them graphically as...
A. Applications
B. Today screen/Tray
C. Task bar
D. Top/Bottom overlay
The first group, Applications, I wouldn't even bother with. They tell you what the battery level is, and sometimes more information, but you do need to actually run the application. So there's no quick view of what the battery level is at any time.
The second group is nice if you're on the Today Screen a lot. They typically have nice graphics. However, they'll only be on your Today Screen, and take up space there. Very often the larger "Does everything!" applications that use the Today Screen will have one of these, typically along with indicators for memory and storage space.
The third is a bit nicer already. You can see it on any screen, as long as the task bar is in view. There's just one problem - they take up space on the precious task bar - and there's not a whole lot of space there on a QVGA device when in portrait mode. Some solve this by putting a tiny little bar underneath the clock - so much for getting a readout 'at a glance', though. In addition, any application that hides the task bar, will hide that indicator as well.
The last category, at least for me, is ideal - and Batti belongs in that category. Thes are the battery indicators that are usually just a line of a few pixels (or even 1 pixel, like Batti) high, going across the top/bottom of the screen. They're always visible, and you can easily tell how full your battery is even if it's just a white solid bar (such as what's in MagicButton).
They usually come in two flavors.. a solid bar going from left to right, or individual little bars, so that you can easily count in percentages. One of SPB's products comes with one of these, for example. Which style you prefer is really a matter of personal likings.
What's extra nice about Batti is that you can set it up to change the color of the bar at two percentages (e.g. 33% for 'low' with an orange color and 10% for 'critical with a red color), all user-definable. It can also indicate charging, and has a nice textual read-out of charge, voltage, temperature, etc. if you click on it (optional). The frequency with which it updates can also be setup. Some of the battery indicators poll every second, for example, thereby actually draining the battery a good bit itself more than it needs to. I have mine set up to update every minute, which is more than enough.
The *only* thing I would love to see added to it is alarms for the two percentages - which I've requested from the author, but haven't heard back from him as of yet Some of the other battery indicators may have alarms, so that might be something to keep in mind.
Batti
Where can I download Batti from ?????
http://www.google.com/search?q=pocketpc+batti
Battery meter.
I downloaded Batti and I dont think its very good at all !!!. The battery level indicator that comes with Pocket Hack Master is way better. However what I realy Real Real need is the OLD battery level software from WM2003. You know the one with red and green in the settings folder. Unfortunately I deleated it when I hard reset my phone.
Please anyone out there who has the old WM2002/3 still on file. Can you send me a copy of the file I need to make that work again.
Thankyou
Rob
I guess you'd have to state your reasons for liking the one that comes with Pocket Hack Master better
There's three things that are at play, to begin with...
1. Pocket Hack Master isn't free. Of course, if you are looking into the functionality it offers (CPU clock speed tweaking, etc.), then its built-in battery meter is a nice bonus when you do buy it anyway.
2. Pocket Hack Master doesn't run on all devices. Due to the fact that it is an application mostly geared towards CPU clock speed tweaking, it will refuse to run on unsupported processors such as the TI OMAP processor. I believe this doesn't apply to the Blue Angel, but does to e.g. the Wizard.
I have an HTC Wizard.
3. Personal preferences. Everybody will prefer their own style of battery meter, etc. You didn't fully explain why you like Pocket Hack Master's better, and unfortunately I can't fully review it as Pocket Hack Master refuses to work on my device. However, from some screenshots it appears that you can only set colors for battery or A/C (i.e. no change of color based on the charge level), the size appears limited (though you can make it a small 2px bar or a series of 4px blocks), and you can't set the refresh rate. On the other hand, you can fully control its positioning and hide the border. All in all - though again.. I'd have to actually be able to run it to make sure.. I haven't seen an screenshot of the 'gradient' method for example - I'd still have to stick with Batti on features alone.
Hopefully they'll add TI OMAP support soon, as it would be worth getting for that, for sure
For the curious, Batti was updated to version 1.4.
Added: Sound Events
Added: Option for turning off the frame around Batti
Added: Option for blinking on critical level
Added: Battery status on Info page (Charging, On AC, On Battery)
Added: Custom color for charging*
Some bugfixes
* charging is different from being fully charged. Sound events can be defined for charge start and charge end as well.
And I forgot to mention in my main rant that you can change the strings for localization easily - most of the main languages are already available for download
My question about this utilities, is which takes least memory space and battery life?
I hate to install something very usefu which on the downside slows down the device and makes me go crazy with the battery.
Of course anything that continuously monitors the battery performance will take up extra battery life itself, though it's typically negligable. Batti itself can be configured to poll only every N seconds - I have mine set to 60 seconds, but obviously there's no real reason to even set it to this frequency - the battery won't drop that much in a minute
As for memory use, I can't really report on others, and you have to keep in mind that several of the battery monitors are part of a larger whole; and if you want the larger whole anyway, then you typically won't lose any additional memory from enabling the battery monitor functionality. For example, MagicButton has a battery indicator line as well.
Batti takes up roughly 40KB
If you want a pure battery monitor proggie:
http://forum.xda-developers.com/showthread.php?t=364278
One of the best
Judging by my searches, this cannot be done ...
I can make the clock in the titlebar appear on all programs.
I can replace the clock in the titlebar with the battery icon.
So why am I unable to put the battery icon in the titlebar of all programs?
Or can I?
As there is no reply yet, perhaps I can suggest a different approach?
I use the Freeware app Batti version 2.4. You can Google it. This puts a thin row of pixels across the top of the title bar. One of the options is to make it "always on top" and this will ensure that it is visible even when an app takes over the full screen. It is a very small program 164kB which runs at startup. You can even set how many pixels high is the strip that shows battery status, and change its colours while on battery and charging states. Of course it takes up no space on the title bar itself (apart from say 3 pixels vertically) and therefore you can display clocks etc as well. Thoroughly recommended.
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a light image, 15 a dark image.
Renate NST said:
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a dark image, 15 a light image.
Click to expand...
Click to collapse
Nice find! I didn't know that was a B/W threshold. But I think you meant "1 gives a light image and 15 a dark image".
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too).
What I actually use for "contrast" adjustment in NoRefreshToggle is a different approach. Using a fixed threshold of 14 (dark image), I've managed to lower the black level (turning it more greyish) to achieve a smaller color range. This way, the dither patterns appear more often. However, my technique to achieve this effect is not so elegant: I overlay the entire screen with a semi-transparent white pane. This has the inconvenient of controlling the pane visibility: whenever A2 mode is turned off (by user or system), I need to hide the pane View.
If I could temporarily avoid the automatic changing of screen modes by the system, this would be much simpler. I've had no success at this issue so far.
marspeople said:
I think you meant "1 gives a light image and 15 a dark image".
Click to expand...
Click to collapse
Yup, good catch. The preceding two sentences were correct. I edited the third.
I have a demo panning grayscales. It's easy to see where the threshold is occurring. Shown below.
Oh! I did see something about the dither modes.
They would certainly be useful for video, less so for text.
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
Click to expand...
Click to collapse
i seems to me that n-r mode would be much more usefull if would could regulate when its on a and when off. Its quite pain running the app again and again. it seems to me that quicker reaction is much better than nicer pictures in average use - pdf reading, browsing, video, managing system...
marspeople said:
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too)
Click to expand...
Click to collapse
I don't think the dithering can be 'tweaked' as such. It's caused by the reduction of 24-bit color images to the 16-bit colorspace of the OS. Dithering is performed by the graphics hardware to prevent obvious colour banding, and there's no OpenGL functions to control dithering parameters.
The A2 mode seems to choose a threshold value for black in the 16-bit colorspace. Values above this are white. In order to obtain black and white dithering we have to pick values in the 24-bit colorspace which all lie in the same 16-bit band.
The easiest way I've found is to keep the R and G values at 255 and vary the B value. I think the default threshold lies at 255,255,198. If you start at that and increase the B value you get 7 dithered grey shades before you reach white.
Guys, as far as i know, eink display is build of tiny capsules, much smaller that one pixel is, and a chip is joining them into pixels. So mayby there is a way to divide single pixel into 2 or even 4? It is much much work, but it would make us easier draw some tones of monochrome? Example: to get dark gray, instead of displaying one of five black pixels white, we can make one's "subpixels" 3/4 black, 1/4 white.
Does it make sense/do you get it?
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
Click to expand...
Click to collapse
I agree with you. But having temporary exclusive control of A2 mode would make my application more efficient. I don't intend to use A2 system-wide.
Renate NST said:
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Click to expand...
Click to collapse
I just tried this but I've got nothing more than a simply darker and checkered image. I don't understand how it would be better.
marspeople said:
I don't understand how it would be better.
Click to expand...
Click to collapse
Well, halftone screens have been around forever.
Think of it this way, it would give you two different thresholds.
With a bigger pattern you would get more thresholds but a coarser pattern.
That is always the way with dithering or halftone.
Probably a screen would not work well with an underlying dither.
A useful observation from http://forum.xda-developers.com/showthread.php?t=1502723&page=11 is that by listening to the screen you can hear screen activity.
After a quick test I suspect ONESHOT mode allows the screen to enter a power saving mode (in which the screen is completely silent) after a few hundred ms of inactivity, while ACTIVE prevents it. No idea whether there are other issues involved.
The native Reader.apk uses GU, ONESHOT_ALL when turning pages.
Every 6th page it uses GC, ONESHOT_ALL.
In an overnight test with the nook screensaver / lock screen mode inhibited by my application and no screen updates, I obtained power consumption of 0.75% / hour with ONESHOT mode. In a previous test with ACTIVE mode I got ~7% / hour with the same scenario(!)
With fast screen updates of ~ 1Hz ONESHOT does not appear to give any power saving benefit over ACTIVE mode, and a quiet hiss can be heard from the screen at all times in both modes at this refresh rate. I think this indicates the ONESHOT mode allows the screen to enter a power saving mode after a period of inactivity.
Neither of these were scientific tests but I strongly suggest trying ONESHOT mode in favour of ACTIVE whenever using A2 mode.
Well, there must be some benefit sometime to the ACTIVE mode or they wouldn't have it.
It's hard to differentiate the different modes, but it seem that ACTIVE responds quicker with less delay.
I switch to ACTIVE_ALL, A2 for panning and switch back to ONESHOT_ALL, AUTO afterwards.
(I don't use full-time A2).
See my demo of panning: http://forum.xda-developers.com/showthread.php?t=1563645
I'm running about 7%/hour drain. My Nook is not suspending when I do a simple power button click. I don't know why.
A few folks seem to be using EpdController in a useful manner.
Their use of Java reflection is clever, but it's not supposed to be that difficult.
I wrote a Java stub (basically declarations) for EpdController and wrapped it in a jar.
If you just put this jar in your compilation classpath with your normal android.jar
then you will be able to use the EpdController without all the fuss and muss.
For example, in my latest (unreleased) version of UsbMode I want the blinker to go on and off cleanly:
Code:
EpdController.setRegion("UsbMode", EpdController.Region.APP_3, blinker, EpdController.Wave.DU);
That's it, one line, no initialization.
The EpdController class was designed to handle such trivial uses.
Note: This jar itself has no functionality, all the method bodies are {}.
You will have to import android.hardware.EpdController
The 1.2 update uses a different EpdController and has a new EpdRegionParams.
This may or may not break code written for previous versions.
The best way to write code to use EpdController is to have it detect if there is no Epd
(i.e. for other devices), the old version or the new version.
Wrap a try/catch around a Class.forName("android.hardware.EpdController").
Wrap a try/catch around a Class.forName("android.hardware.EpdRegionParams").
The new epd.jar in the signature will allow you to compile without using redirection both the old and the new.
For details on the changes, see: http://forum.xda-developers.com/showpost.php?p=35390192&postcount=8
Bump & additional info.
By experimenting and reading documentation for other eInk controllers I've figured out the following:
Controllers support different algorithms for updating the pixels depending on the precision of the gray scale required and the compensation for previous ghosting.
On the Nook, we have the choice of waveform modes:
GC
GU (gray update)
DU (direct update)
A2
GL16
AUTO (auto selection of algorithm)
The screen can be divided up into regions where different algorithms may be used.
Some controllers support 15 regions, ours supports 8.
4 of these regions are earmarked for system usage, specifically:
Toast (popups)
Keyboard (soft keyboard layout)
Dialog (popups)
Overlay
The remaining 4 regions are left for the user.
Note: "HwRegion" is an enum for the complete 8 regions, "Region" is an enum for the 4 user regions.
An example: In my audio recorder I have two regions set aside for the VU bar graphs.
By setting these two regions to DU I get rid of update clutter and the response is quicker.
Currently, the EpdController in the Nook only operates with portrait coordinates.
If you wish to use this while in landscape mode you will have to rotate the coordinates first yourself.
It's sometimes hard to see exactly what/if some EPD setting is doing.
A good way to check it is to set a region for one half the width of whatever active graphic element you are trying to improve.
The difference can be very clear.
Renate NST said:
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Click to expand...
Click to collapse
Excellent work! Do you happen to understand/can write up what the various fast mode/no refresh hacks do/how they use these different modes?
I've had X 'running' on my nook but only by triggering a full refresh every few seconds, and wondered how I could be more selective.
My reading of Norefresh was that it was doing something like parsing android log structures for areas that have changed.
Is there an easy way to trigger a refresh of part of the display from userspace, preferably directly on the driver or fb?
As for where the dithering is done, my guesswork is this is done by a blob running on the DSP module within the OMAP (which is perhaps the only interesting use of it I've seen).
Dave
Just done some playing writing directly to the entires in /sys/class/graphics/fb0 ; so for example:
echo -n 100,100,200,200,0,14 > epd_area
echo 2 > epd_refresh
causes the square 100,100->200,200 to be refreshed
the 14 being REGION(8)+CLEAR(4)+ONESHOT(2)
the 0 is wvfid+threshold*65536 I think.
I've put some code that runs under X to trigger updates; here (actually the comment is wrong, it's currently using oneshot+clear);
I never managed to get active to work.
http://forum.xda-developers.com/showthread.php?p=42393733#post42393733
Dave
Thanks for your time. Two questions, #1: I've been around here and throughout other sites, and found (it seems) dozens of different options but none have seemed to work regarding getting an object to follow a CIRCULAR progress bar. In this case, I have a simple clock that I would like to have a sunrise icon and sunset icon (each) move around the outside the clock at the appropriate time. I have tried multiple codes and combos to no avail. I have successfully managed to achieve this result on a straight prog bar using [oy]$(-34+(#BLEVN#*2.70))$[/oy]. Those are, of course, my coordinates plugged in. I've found so many different "Oh, do this, this'll work" codes that don't work, I won't bore you with them (including this one http://forum.xda-developers.com/showthread.php?t=2563932). At any rate, any help would be appreciated.
#2: Is it possible to set up a 12 hour progress bar clock that handles just am and/or just pm?
Thanks again.
#1 Take a look at the Zooper standard analog Clock
#2 Use the 24h. For am use min 0 max 12 and for pm use min 12 max 24
Sent from GT-I9505 via Tapatalk
ibashmuck said:
Thanks for your time. Two questions, #1: I've been around here and throughout other sites, and found (it seems) dozens of different options but none have seemed to work regarding getting an object to follow a CIRCULAR progress bar. In this case, I have a simple clock that I would like to have a sunrise icon and sunset icon (each) move around the outside the clock at the appropriate time. I have tried multiple codes and combos to no avail. I have successfully managed to achieve this result on a straight prog bar using [oy]$(-34+(#BLEVN#*2.70))$[/oy]. Those are, of course, my coordinates plugged in. I've found so many different "Oh, do this, this'll work" codes that don't work, I won't bore you with them (including this one http://forum.xda-developers.com/showthread.php?t=2563932). At any rate, any help would be appreciated.
#2: Is it possible to set up a 12 hour progress bar clock that handles just am and/or just pm?
Thanks again.
Click to expand...
Click to collapse
#1: Moving things circular is a bit different from moving this along a straight line. For circles you need three parameters in Zooper: thie radius of your circle ([ar][/ar]), the sweep angle of said circle ([as][/as]) and finally the rotation ([r][/r]). The first one is static and the other two depend on what you are trying to do. You need to determine the size of your circle in degrees (360 for full, 180 for half etc.) and then determine in how many steps you need to cut that size. For something that moves with the minutes of the hour it would be 60 for instance. Then your amount of degrees per minute is 360/60 and if you multiply that with the numbers of minutes #Dm#, you get your current position and rotation. So for something to move around a circle based on the minutes of the hour you would need these advanced parameters:
[r]<whatever size>[/r]
[as]$(360/60*#Dm#)$[/as]
[ar]$(360/60*#Dm#)$[/ar]To apply this to your idea, you need to figure out in how many steps you want your circle to be broken down to (I would guess 12) and then what's your variable you want to multiply with (#ARK# maybe). With these values it should position the symbol on the hour of the sunrise.
I hope this helps you out and if not, don't hesitate to ask
#2: I think so but you probably would have to work with some advanced parameter conditionals to check whether it's currently am or pm. This depends on what exactly you are trying to do. If you can give me more details I can try to think something up.
kwerdenker said:
#1: Moving things circular is a bit different from moving this along a straight line. For circles you need three parameters in Zooper: thie radius of your circle ([ar][/ar]), the sweep angle of said circle ([as][/as]) and finally the rotation ([r][/r]). The first one is static and the other two depend on what you are trying to do. You need to determine the size of your circle in degrees (360 for full, 180 for half etc.) and then determine in how many steps you need to cut that size. For something that moves with the minutes of the hour it would be 60 for instance. Then your amount of degrees per minute is 360/60 and if you multiply that with the numbers of minutes #Dm#, you get your current position and rotation. So for something to move around a circle based on the minutes of the hour you would need these advanced parameters:
[r]<whatever size>[/r]
[as]$(360/60*#Dm#)$[/as]
[ar]$(360/60*#Dm#)$[/ar]To apply this to your idea, you need to figure out in how many steps you want your circle to be broken down to (I would guess 12) and then what's your variable you want to multiply with (#ARK# maybe). With these values it should position the symbol on the hour of the sunrise.
I hope this helps you out and if not, don't hesitate to ask
#2: I think so but you probably would have to work with some advanced parameter conditionals to check whether it's currently am or pm. This depends on what exactly you are trying to do. If you can give me more details I can try to think something up.
Click to expand...
Click to collapse
Thanks for the response. That's actually the first parameter that I found and tried to work with, and, like then, I still can't get it to work. My "hour clock" numbers are:
x= 60
y= -210
w= 520
Using #Dh#, min 0, max 12
Putting numbers into the codes you gave...
[as]$(360/12*#ARh#)$[/as]
[ar]$(360/12*#ARh#)$[/ar]
...(or even #ARK#) still sends the icon low and to the left, as you can see in the second screen shot (I've enlarged it to show it's position better). I'm living up to my namesake with this, I know, but my guess is I'm missing one small bit that's throwing me off. Apologies, of course.
Is image persistence normal for S20's screen or OLED screens in general?
For example, playing a bright video game with black aspect ratio bars, leaves a lasting persistent image, where on dark pastel backgrounds you can clearly see where bars and game were.
Or writing a long article, leaves remnants of Android's nav. buttons, Chrome's address bar, and even keyboard visible, when tested on dark pastel backgrounds.
These persistent images gradually disappear, but it takes a long time to disappear completely. Do you experience something similar to this?
Thanks.
Scroll down for testing methods, post #5. Start by opening dark gray image, view full image, zoom in, do you see discoloration?
Image retention (persistence) is a somewhat common issue with all OLED. That said you shouldn't be experiencing it unless your constantly rocking your screen at 100% brightness, or near there, for hours on end.
I found this cNet article which explains it really well.
https://www.cnet.com/how-to/oled-screen-burn-in-what-you-need-to-know-now/
scaredy-cat said:
Is image persistence normal for S20's screen or OLED screens in general?
For example, playing a bright video game with black aspect ratio bars, leaves a lasting persistent image, where on dark pastel backgrounds you can clearly see where bars and game were.
Or writing a long article, leaves remnants of Android's nav. buttons, Chrome's address bar, and even keyboard visible, when tested on dark pastel backgrounds.
These persistent images gradually disappear, but it takes a long time to disappear completely. Do you experience something similar to this?
Thanks.
Click to expand...
Click to collapse
The Galaxy S7 and S8 had issues with Screen Burn which Samsung improved going forward from the S9. If the ghost images gradually disappear it isn't Screen Burn which causes permanent discoloration. If under warranty you may wish to get the device replaced, it doesn't seem the problem will correct itself over time. The other options I would consider are uninstalling apps which you enabled just before the problem appeared or performing a Factory Reset.
if you're playing games and the background is constantly moving, then there should be little, or no image retention. However, if you are using Google Maps and high brightness and stationary for a long period of time (eg stuck in traffic) then I would consider some image retention could be present.
Thank you for your answers. Bold text for topics. Testing methods at the end of this reply.
Was not aware OLED screens' image retention is such a common issue, but I knew OLED screens are prone to burn-in, read about it online, and saw it on my relatives' older devices, so out of the box I turned on the dark mode and changed wallpaper to black.
I preferred regular Android's navigation buttons to gestures, because of ergonomics, due to phones center of mass (wish it was more bottom heavy), when using with one hand, balancing phone while performing gestures always feels like I'm about to drop the phone, I also find gestures to be slower, simple tap vs sliding your finger. And on top of that, I have carpal tunnel syndrome, so it's much easier to simply reach and tap. But now I started using gestures, as a burn-in preventative measure.
By the way, having Chrome open for around 20 minutes, and quickly switching to Display Tester's BurnIn detection, I can already distinguish Chrome's address bar section, and clearly see tab switcher button. This will gradually disappear, but the fact that afterimage appears so quickly and remains for so long is concerning, since I feel such image retention might indicate my display may be prone to burn-in, but of course, I don't know this for sure, just my uneducated guess.
Having dark mode keyboard open for around an hour, and I can see remnants of it even on grey backgrounds of folders.
Back to reply..
I never use my screen at full brightness, it's always set to somewhere around 50%, and as I said earlier, image retention starts to occurs in a matter of minutes. Images do gradually disappear, but it takes a long time, and when I use screen for hours with static elements, it felt like it took awfully long time to disappear, but to determine how long exactly it takes for them to appear and disappear, I need to do more thorough testing.
Yes, when playing games, indeed, a lot of things are moving, except for Heads-up Display, but I first noticed this image retention issue playing an older video game called "Super Cat Bros". That game is not optimized for such wide-screen phones as S20, so on each side you have a black bar, display is split into 3 sections - bar-game-bar. That game is very colorful and has lots of solid colors, so after I finished playing, in dark user interface backgrounds I noticed discoloration, later looking at solid color backgrounds l noticed clearly where each section was, so bar-game-bar. Because sides of a display were turned off, and all action happened in the middle, you can clearly see which part of the screen was the most active.
This is why I'm coming to conclusion, that dark mode alone is still only a small part in burn-in prevention, you should blackout everything, including websites (I remember firefox had plug-in like that, capable of replacing background and font colors), switch to a dim keyboard preferably without visible keys with orange-red colored font, download oled friendly icon packs, watch movies cropped in, so you're not left with permanent discoloration in place of "black bars", and play games full-screen, only then wear will be uniform. Seems like too much work. I wish micro-led displays would become widespread sooner.
I don't think factory reset or uninstalling apps will help, because it appears to be not software related.
At least not software user can update, such as display's firmware, but I don't know for sure just how independent display is from other phone's guts. Even then, I don't think firmware can fix this.
The phone is under warranty, since it's new, used for a few moths, and unmodified, but sadly is probably not an option, because in my country, gaslighting customers is fairly common. Service center will probably take it away for a few weeks, then return it scratched up, and say they didn't find any issue. So unless it's a serious burn-in, that's visible always and on every background, it'll be extremely difficult to make a return, and even then they'll probably tell it's normal wear, but then at least you can without explaining too much contact consumer protection and show them the problem.
Software used for discovery and testing:
• Super Cat Bros (video game)
https://play.google.com/store/apps/details?id=com.FDGEntertainment.SuperCatBros.gp
Play it for an hour (or more) and then test on solid darker pastel colors, do you see discoloration? Report for how long you played and how long discoloration was visible. Do not reopen game when retesting discoloration, because it may appear permanent. I know some people are not good at seeing minute differences in shades, but at first it should be very obvious which parts were black bars and part where game ran.
• Display Tester (app)
https://play.google.com/store/apps/details?id=com.gombosdev.displaytester
Very good display tester, free, lots of features and tests, and works on wide-screen displays, enable "use immersive mode if possible" in the settings. I think default color in BurnIn tester is very good at revealing discoloration, but you can play with sliders, just remember position which reveals discoloration the best.
• I'll also attach solid color image, which works for revealing discoloration.
And another dark gray image, which also helps reveal discoloration, use in dark room at around 50% screen brightness (play around), no matter how much you zoom in or out, it appears like screen has gradient, notifications bar icons are also visible, not sure if it's temporary or a permanent discoloration. I recommend opening these images with a gallery app, set to full screen, or simply pinch to zoom, and tap screen one time to hide gallery's UI elements. Tilt phone left and right, move towards and away from yourself, do you see discoloration?
You can also open them up with browser, and examine your screen, but I found you can't hide all UI elements, so better use gallery or other image viewer.