While messing around with the colors and themes in the registry I wondered if it would be possible to make the ChromeColor value transparent. This value applies to the background of the keyboard, as well as the "drawer" type thing (were all the buttons are kept in apps). I think it would be interesting to see and could help free up some screen space (visually, not necessarily functionally). However, I'm a little timid in changing the value myself. I'm not good at anything related to coding really (only small time practice) so I don't know if its possible to change the value to simply "transparent" and have it take effect. The values seem strange because they're FFCCCCCC, while online they typically seem to be FFCCCC so I'm assuming it's CSS values (is there a numerical value for transparent?). I'm worried that if the value is changed to a non numerical value that something will go wrong.
Has anybody tried this? If you know if this works/try it out please let me know as I think it could be really cool for the ChromeColor to be transparent.
Sure, this is possible. The first to digits are the transpareny values. In Hexadezimal-Code F is the highest number. So FF is fully untransparent. Fully transparent is 00 in front of the colour value. 0,1,2,3,4,5,6,7,8,9,A,B,C,D,F this is the order and with that you can change the percentage of transparency.
For example the code #00000000 is fully transparent and black.
JoniJi said:
Sure, this is possible. The first to digits are the transpareny values. In Hexadezimal-Code F is the highest number. So FF is fully untransparent. Fully transparent is 00 in front of the colour value. 0,1,2,3,4,5,6,7,8,9,A,B,C,D,F this is the order and with that you can change the percentage of transparency.
For example the code #00000000 is fully transparent and black.
Click to expand...
Click to collapse
Doesn't fully transparent mean there is no color?
JoniJi said:
Sure, this is possible. The first to digits are the transpareny values. In Hexadezimal-Code F is the highest number. So FF is fully untransparent. Fully transparent is 00 in front of the colour value. 0,1,2,3,4,5,6,7,8,9,A,B,C,D,F this is the order and with that you can change the percentage of transparency.
For example the code #00000000 is fully transparent and black.
Click to expand...
Click to collapse
Alright, thanks for that info. #00000000 turned out to be white (I think), but #00FFFFFF is truly transparent. It's kinda neat, only problem I've identified is that it doesn't take effect in all apps. In the messaging app when I bring up the keyboard its transparent for a second, and then goes to solid black. Not quite sure why thats happening if its supposed to be reading the same registry value. Also, some of the drop down menus (when an app has an error/something at the top of the screen like the music) don't have the backing so the text is unreadable. I think it's best to just stick with solid black.
Is there an app for this? I'd like to know how to do it.
Sent from my SGH-i917R using Board Express
kr3w1337 said:
Is there an app for this? I'd like to know how to do it.
Sent from my SGH-i917R using Board Express
Click to expand...
Click to collapse
Currently the only way to change theme colors (outside of tile colors) is modifying registry values. I'm using the registry editor from here: http://forum.touchxperience.com/viewtopic.php?f=20&t=593 (just look in the attachments box for the newest version).
Once you have the app open you need to go HKEY_LOCAL_MACHINE -> ControlPanel ->Themes. The "0" folder is for the light theme and the "1" folder is for the dark theme.
I'd recommend checking out this thread if your curious about changing some things in the registry: http://forum.xda-developers.com/showthread.php?t=907971
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.