Note: This is a work in progress.
Note: All Image manipulation is done with GIMP.
Note: This guide is mainly for the A101 but can also be applied for the A70.
I was getting sick of not be able to take a good picture and use it as a wallpaper so that it looked good. I know there is an alternative "MultiPicture Live Wallpaper" but that thing is a memory hog.
PART 1
So I came up with this picture it's a PNG of 1200x1024. The different grids are the following sizes.
Blue: 8px
Green: 16px
Red: 32px
White: 64px
When this is set as a wallpaper we can finally see what is happening to the image.
Here are the screenshots for the 5 screens of the Stock Launcher of the Archos 101.
Screen 1
Screen 2
Screen 3
Screen 4
Screen 5
Since the status bar can not be hidden on the Stock Launcher we loose 32px at the top and on the right with the soft buttons we loose 40px. When positioned on the first screen we have a good view of the top left corner (1024x600) of the reference picture.
Now lets get to work with this picture below.
Size: 1680x1050
So what do we need to do. The result must be an image with a size of 1200x1024 for the A101 and 960x800 for the A70 where only the top 600px (A101) 480px (A70) will be visible in landscape mode.
Scaling the image to a height of 600px and keeping the aspect in mind. The result is a picture of 960x600
On the bottom add a 424px black border.
On both sides add a 120px black border.
and the result is
Size: 1200x1024
And the screenshot to prove it works.
This was tested with the Stock Launcher and ADW.Launcher.
PART 2
So this worked out because the original picture has a black background. So here is the solution for other pictures.
I made a multi layer xcf file with GIMP to address the problem. You can download it here for the A101 and here for the A70.
Open WallPaper_cropping.xcf in GIMP.
Select the "Background" layer.
File -> Open as Layer -> select the picture you want to crop.
Scale the layer to 1200px width and keep the aspect correct.
Position the layer so that the visible part looks good.
Turn visibility on/off so that only the layers "Background:, "The Picture", "Black Not Visible Part" are turned on.
Save the image as PNG with option "Merge Visible Layers"
Send to archos and apply as wallpaper with the Crop Wallpaper app and use the "Overall" button.
This is all for today. Next We'll see if we can do something with extending the background instead of cropping it.
Reserved for future use
Reserved for future use 2
reserved for thanks ;-)
many thanks
Worked fine for landscape But when I turn it portrait there is a black bar at the bottom - How do I get it to fill in that black space??
Using ADW Launcher if that has any effect on it...
Would put up a screenshot but the forum won't let me...
martinjh99 said:
Worked fine for landscape But when I turn it portrait there is a black bar at the bottom - How do I get it to fill in that black space??
Click to expand...
Click to collapse
There is no way to do both landscape and portrait at the same time. So you have to choose.
ah ok- Thanks anyway.
Thanks wdl1908. It will be difficult for me to explain because of my poor english. But with your settings and my A70it it didn't (the image was too high). So I have set the top of my image at 183px and the bottom at 644px and now it's perfect. Maybe someone with skills could check those values cause I'm a newbie.
Thank you very much.
nikokroko said:
Thanks wdl1908. It will be difficult for me to explain because of my poor english. But with your settings and my A70it it didn't (the image was too high). So I have set the top of my image at 183px and the bottom at 644px and now it's perfect. Maybe someone with skills could check those values cause I'm a newbie.
Click to expand...
Click to collapse
If you attach your original wallpaper I'll look at it to see what the best method is.
So this is my actual wallpapaper. In landscape I see everything of the middle layer and not the 2 others (normal). And in portrait I don't see the face of the guy on the first layer. But this is not important cause those layers are just there to fill the blanks in portrait mode.
The original picture was found on socwall and was 2500*1324px
nikokroko said:
So this is my actual wallpapaper. In landscape I see everything of the middle layer and not the 2 others (normal). And in portrait I don't see the face of the guy on the first layer. But this is not important cause those layers are just there to fill the blanks in portrait mode.
The original picture was found on socwall and was 2500*1324px
Click to expand...
Click to collapse
Very nice wallpaper. I usually don't bother with the portrait mode as long as the landscape mode is shown correctly. I would just cut out the middle part and use that to fit into the portrait visible part of the template.
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
Hi all, please see the below thread. Only sharing the info as this was posted on the Verizon N4 forum.
http://forum.xda-developers.com/note-4-verizon/general/root-want-to-modify-dpi-t2960644
Hope this helps...
As indicated below some touchwiz native apps are affected.
List of known affected applications by changing DPI settings:
S-View (for S-View covers -- slightly misaligned but functional)
Touchwiz Stock Dialer (slightly misaligned but functional -- other non-stock options exist such as Hangouts or ExDialer)
Fingerprint lockscreen (arrow pointing to finger print scanner off center)
Exchange email (stock Samsung Email)
Stock Camera App
Just FYI to get some easy download links:
http://forum.xda-developers.com/note-4-verizon/general/root-want-to-modify-dpi-t2960644
Enable USB debugging on yer phone
-> http://www.mediafire.com/download/a4hd8y0c1iakysk/Samsung-Usb-Driver-v1.5.49.0.exe
Samsung USB drivers you'll need installed
-> http://forum.xda-developers.com/showthread.php?p=48915118#post48915118
ADB / Fastboot installer
navigate to C:\adb\ and then run the command they give in the thread
adb shell wm density 540
(not confirmation will be sent but your phone should prompt you to 'allow' your computer to send adb commands to it.).
Restart phone
DPI settings are now at 540. original DPI settings are 640 BTW
imnoob55 said:
Hi all, please see the below thread. Only sharing the info as this was posted on the Verizon N4 forum.
http://forum.xda-developers.com/note-4-verizon/general/root-want-to-modify-dpi-t2960644
Hope this helps...
Click to expand...
Click to collapse
I came across that thread a few hours ago. It's pretty neat to be able to drop the density and make more use of display space (could even drop it down to 384 and make it look more like a tablet), but it has its problems. Samsung apps (Dialer, camera, S Note, S-View, etc) will lose their screen alignment and/or only cover a portion of the screen when altering the density. Finding an alternate dialer was easy enough, but I'm having trouble finding a camera app similar to stock in quality, and was unsuccessful at replacing the S-View...
redphazon said:
I came across that thread a few hours ago. It's pretty neat to be able to drop the density and make more use of display space (could even drop it down to 384 and make it look more like a tablet), but it has its problems. Samsung apps (Dialer, camera, S Note, S-View, etc) will lose their screen alignment and/or only cover a portion of the screen when altering the density. Finding an alternate dialer was easy enough, but I'm having trouble finding a camera app similar to stock in quality, and was unsuccessful at replacing the S-View...
Click to expand...
Click to collapse
Yup unfortunately that is a side-effect of doing this. Only way to do it that I am aware of conventionally would be via xposed or loading in custom TW apps, both not possible. Hangout dialer works well, for this. TW stock browser is not affected. My S-Note is not affected either, too. Dialer and S-View are (not unusable, they just are not center-aligned any longer as their height/width are set on static widths rather than proportional % when Samsung set up the layout.) Maybe they'll change that in L.
BTW I use Nova for launcher and Hangouts as my dialer. I do use an s-view case, though, which is of course impacted.
imnoob55 said:
Yup unfortunately that is a side-effect of doing this. Only way to do it that I am aware of conventionally would be via xposed or loading in custom TW apps, both not possible. Hangout dialer works well, for this. TW stock browser is not affected. My S-Note is not affected either, too. Dialer and S-View are (not unusable, they just are not center-aligned any longer as their height/width are set on static widths rather than proportional % when Samsung set up the layout.) Maybe they'll change that in L.
BTW I use Nova for launcher and Hangouts as my dialer. I do use an s-view case, though, which is of course impacted.
Click to expand...
Click to collapse
I'm also using Nova Launcher. I did download ExDialer at first, but I went to Hangouts Dialer instead since ExDialer has a trial period and costs money.
S Note is largely unaffected yes, but when you open the camera for copying documents, the square used for aligning the camera with the document is off-center. It doesn't seem to hurt functionality in any way, though. Oddly enough, the camera when used in S Note is fullscreen...
As far as S-View goes, I'm thinking about removing the flip cover. S-View is nice, but I'm always trying to not get smudges on the cover screen on top of the phone display, so the cover is a little bit cumbersome to me when holding it. Seeing how much better the phone looks at a lower density makes me lean even closer to just getting rid of it. That leaves me with just the camera replacement...
Exchange email is also broken... when you reply to an email, the screen font is set to eleventybillion.
-----
Sent with my Galaxy Note 4
Can anyone confirm if this impacts the play store? Typically changing the dpi on the whole device would prevent the play store from downloading some apps.
Sent from my SAMSUNG-SM-N910A using XDA Free mobile app
jfenton78 said:
Can anyone confirm if this impacts the play store? Typically changing the dpi on the whole device would prevent the play store from downloading some apps.
Sent from my SAMSUNG-SM-N910A using XDA Free mobile app
Click to expand...
Click to collapse
I haven't seen any problems with the Play Store yet, though I haven't been installing much of anything, either. The few apps I've installed so far gave me no trouble.
Also, just found out that the stock camera has no problems with accurate button detection when the phone is turned sideways for landscape rotation, though it's still not fullscreen. You have to guess where the buttons are on the screen in portrait when the density is changed.
Couple of tips:
if you get an error about the device being offline make sure you've got the current ADB installed. The link provided for the adb and fastboot didn't work for me because the file didn't install. The program is just an auto run zip file. you can open with 7-zip and just extract the adb files.
also if you get an error about the device being unauthorized you must select no action on the windows pop up and always perform this action. the phone should then get a pop up with the RSA key number and ask you to authorize. hope this helps.
540 DPI is pretty nice.
I was okay with the dialer and lockscreen, but the camera made me go back to 640. In vertical shooting mode, the touch points for all the icons, including the shutter button, is misaligned and is very annoying. What a shame as 540 looked AWESOME.
cj00ta said:
Exchange email is also broken... when you reply to an email, the screen font is set to eleventybillion.
-----
Sent with my Galaxy Note 4
Click to expand...
Click to collapse
Thanks! Just added to the top thread under impacted apps
Does this effectively change the resolution? I'm curious if lowering the DPI would give positive improvement to high-end game performance. Can anyone shed some light here?
Conkrete said:
Does this effectively change the resolution? I'm curious if lowering the DPI would give positive improvement to high-end game performance. Can anyone shed some light here?
Click to expand...
Click to collapse
It doesn't change the resolution. What it changes is the drawing size of on-screen content which is directly from the 'dpi setting' of the phone.
It's a little complicated to explain but this is how it works;
The phone's default screen density (DPI) setting 640, this is done because that's how many dots per inch of the physical screen there is (a phone of similar screen size would have a similar dpi). This value is stored in your phone's build.prop and is read by numerous applications, it might not match exactly the 'real' dpi of the screen but its normally very close to it.
By changing it lower in dpi you're instructing to applications you actually have a smaller screen size, thus to fit content (i.e words not being HUGE on a small screen) content is drawn to that dpi setting you're providing in build.prop.
Now to go into why we have certain issues when changing the dpi.
This is basically due to how the app did its layout sizing (do I base content on "actual size" of the screen-size or do I base it on "actual density" of the screen density in build.prop? Most apps, since they're targeting to be used with dozens of devices of all sorts of different sizes, will be designed where the layout of content is dependent upon dpi. A layout would be I want a rectangular box on the bottom that has height 10px and width 100%, so that effectively means the width is based on the proportion of the screen size (the OS controls this, its just a matter of scaling). This is why you once had 5 items to show now has 8 items to show in a listbox. The size of the listbox in this case would be based on actual density while the content (text etc.) inside would be based on actual size (scaling I would think is limited to a min/max actual size for text).
Samsung can get away with this on their stock apps because in their mind when they build their roms they are only going to be used on that specific device. They're starting to go away from this, however, and are starting to make their layouts more typical that of a normal application. You have somewhat less control of the layout going from actual size to actual density.
*keep in mind you can actually set parameters for both. Such as if I wanted something to be 10% in width but only up to 2.5 inches in actual size this effectively means that it will scale until it reaches 2.5" and then scale no longer.
I hope that makes sense. Resolution really doesn't have a role at all in this, you're always at the same resolution (4K) and this is handled by the lower-level kernel and GPU firmware. I don't think there's a way to change this at the app layer but than again I have really no background in android development.
*please if anything comes off as inaccurate please point out, I am from a XAML/.NET development background and linux/unix embedded systems and really I focused on back-end/databases/services and not really front-endy stuff. This is how it is handled in XAML though and I have seen android uses the same principals.
imnoob55 said:
It doesn't change the resolution. What it changes is the drawing size of on-screen content which is directly from the 'dpi setting' of the phone.
It's a little complicated to explain but this is how it works;
The phone's default screen density (DPI) setting 640, this is done because that's how many dots per inch of the physical screen there is (a phone of similar screen size would have a similar dpi). This value is stored in your phone's build.prop and is read by numerous applications, it might not match exactly the 'real' dpi of the screen but its normally very close to it.
By changing it lower in dpi you're instructing to applications you actually have a smaller screen size, thus to fit content (i.e words not being HUGE on a small screen) content is drawn to that dpi setting you're providing in build.prop.
Now to go into why we have certain issues when changing the dpi.
This is basically due to how the app did its layout sizing (do I base content on "actual size" of the screen-size or do I base it on "actual density" of the screen density in build.prop? Most apps, since they're targeting to be used with dozens of devices of all sorts of different sizes, will be designed where the layout of content is dependent upon dpi. A layout would be I want a rectangular box on the bottom that has height 10px and width 100%, so that effectively means the width is based on the proportion of the screen size (the OS controls this, its just a matter of scaling). This is why you once had 5 items to show now has 8 items to show in a listbox. The size of the listbox in this case would be based on actual density while the content (text etc.) inside would be based on actual size (scaling I would think is limited to a min/max actual size for text).
Samsung can get away with this on their stock apps because in their mind when they build their roms they are only going to be used on that specific device. They're starting to go away from this, however, and are starting to make their layouts more typical that of a normal application. You have somewhat less control of the layout going from actual size to actual density.
*keep in mind you can actually set parameters for both. Such as if I wanted something to be 10% in width but only up to 2.5 inches in actual size this effectively means that it will scale until it reaches 2.5" and then scale no longer.
I hope that makes sense. Resolution really doesn't have a role at all in this, you're always at the same resolution (4K) and this is handled by the lower-level kernel and GPU firmware. I don't think there's a way to change this at the app layer but than again I have really no background in android development.
*please if anything comes off as inaccurate please point out, I am from a XAML/.NET development background and linux/unix embedded systems and really I focused on back-end/databases/services and not really front-endy stuff. This is how it is handled in XAML though and I have seen android uses the same principals.
Click to expand...
Click to collapse
Extremely helpful and great info. Possibly the best response I've received from XDA. Thank you for the info. I have found a couple root apps that claim to change resolution but I've been hoping to find a non-root alternative.