Database Info

Different wallpaper per homescreen (or just wider wallpaper)

Hi guys,
As I understand on most modern android devices, the "max" wallpaper size is 960x800. That is, it is 2 screens wide, but pans a percentage of the width from side to side depending on how many home screens you have.
One thing I have been wondering for a while is if there is any way (of course preferably without root, though either way really) to allow for a full 480px wide image for every home screen you swipe through? On an evo, I suppose this would mean a 3360x800 image. A bit extreme, of course, but probably would make for some great customization effects. This functionality idea is basically stolen from the N900.

that would be cool since very screen on my phone has a different theme. tools/games/ media and whatnot

This will let you do just that....Havent tried it on the Evo but theres a comment on the Cyrket page saying it works
http://www.cyrket.com/p/android/com.creativecore.wallpaperplus/

boot animations - should I use png or jpg what's a better decision ?

this is more of a technical question for performance reasons.
.jpg's in my experience can be optimized to be a much smaller file size than a .png.
Granted the quality of the image might suffer a little, but the question here is why would anyone choose .png as their boot animation format since there is no benefit in using the transparency information. Or is there?
Secondly... does the android system somehow process a png animation faster/ smoother than a jpg animation? logic would say no, since the jpg file size is smaller , hence the system can load each frame much faster...yes / no?
One of the biggest issues i have in putting in the effort of making a kick ass boot animation is the loading times due to the large file sequence that it might require...effectively making boot up times logically longer since on top of loading up your system, it also has to load up your boot animation. I find that to be kind of foolish, and defeating the purpose of a boot animation if you know what I mean. Jpg with its optimization options make them a little more ideal for long animations but i want to see what you have to say about all this.

tsakali said:
this is more of a technical question for performance reasons.
.jpg's in my experience can be optimized to be a much smaller file size than a .png.
Granted the quality of the image might suffer a little, but the question here is why would anyone choose .png as their boot animation format since there is no benefit in using the transparency information. Or is there?
Secondly... does the android system somehow process a png animation faster/ smoother than a jpg animation? logic would say no, since the jpg file size is smaller , hence the system can load each frame much faster...yes / no?
One of the biggest issues i have in putting in the effort of making a kick ass boot animation is the loading times due to the large file sequence that it might require...effectively making boot up times logically longer since on top of loading up your system, it also has to load up your boot animation. I find that to be kind of foolish, and defeating the purpose of a boot animation if you know what I mean. Jpg with its optimization options make them a little more ideal for long animations but i want to see what you have to say about all this.
Click to expand...
Click to collapse
There are quite a few posts out there in this section explaining why pngs over jpg. Look them up, will explain why png format was choose for android. My two cents on this...if the bootanimation is so big that it makes you think about alternate formats...then it probably needs revisited. You wont believe how much you can optimze your file with a combination of lesser images and a different fps in the desc.txt.

k will look them up, but i didn't find anything on this actual subject matter.
I am already aware of the points you mentioned and I am already utilizing them to the best of my knowledge, this is just another point of optimization i want to look into.

theidlemonk said:
There are quite a few posts out there in this section explaining why pngs over jpg. Look them up, will explain why png format was choose for android. My two cents on this...if the bootanimation is so big that it makes you think about alternate formats...then it probably needs revisited. You wont believe how much you can optimze your file with a combination of lesser images and a different fps in the desc.txt.
Click to expand...
Click to collapse
Quite a few? I can't find any. If you would be so kind to share a link

Android graphics true facts

Saw this one on google+ and I think it's a nice read and very informative
How about some Android graphics true facts?
I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:
• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.
• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.
• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.
• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.
• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)
• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.
• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.
• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps.
• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)
• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1280x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.
• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.
All credit goes to Dianne Hackborn. Thanks for sharing this!

HAHAHAHA good facts, and very interesting!

Great post

yup, Nice Post!

Interesting observation!

Is the concept of Android's navigation bar broken?

https://plus.google.com/+MarcKrenn/posts/eo6GWmCsrHk said:
(This is an open letter to the Android Design Team regarding the current state of the navigation bar. Long read ahead, you've been warned )
Dear Android Design Team,
I've always been a strong believer in Android's navigation concept and I'm confident it's a corner stone of Android's success. Sure, it might not be the most elegant or transparent solution ("What exactly will happen if I tap on the Back-button?"), but it just works perfectly 99% of the time and that's quite an achievement!
I personally see Android's Back- and Home-button as the ESC-button of the smartphone and tablet generation - even more than Apple's ever so awkward one-button-does-all-solution. Back and Home not only act as universal panic button and therefore reduces the user's fear of doing something wrong but they also make Android more consistent, easier to use across all the different apps (you don't have to search the app-dependent Back-button/solution - if there is one) and they reduces the user's cognitive load, freeing up their cognitive resources for more important tasks.
However, the way we access those wonderful functions - Back, Home and Recent Apps - is completely broken, for three main reasons:
1. Roughly speaking, it's always there when I don't need it, significantly reducing the active screen estate by 48dp, and when it's not there - for instance in fullscreen apps - I realize I'd need it. Yikes! Yes, it sounds paradoxical, but if you think about it, you come to the conclusion that the navigation bar probably doesn't belong on the screen.
Now, I know your reasoning behind the decision to scrap hardware navigation buttons altogether, but maybe the current visualization and placement of the navigation bar is just not optimal.
2. Talking about the placement of the navigation bar, it's probably the worst aspect about it's current implementation. Placing the bar on the bottom of the screen makes it nearly impossible to reach it without hassle - at least when navigating the phone with one hand, which should be considered the standard way of using a phone. At best, the over 90°-movement of your thumb looks and feels awkward, however for most people, especially younger and older ones, reaching the Back-button with their thumbs is just an impossible task. And the bad news don't stop here: The bigger the screen, the worse it gets, making 5"+ phone impossible to navigate with one hand, no matter how great your motor functions are.
I know, it isn't as aesthetically pleasing as the current implementation, but for the sake of ergonomics the current navigation bar should rather be located at the top of screen rather than at the bottom. And the order of the buttons should be altered: The Back-button, which is undeniable the most used one, should be the easiest to reach, so it should belong to the top right (for righties at least).
3. As mentioned above, the current Back-button doesn't provide any visual cues of what's going to happen next, when tapped. The user might ask himself:
"Will I go back within my current app, or will it send me back either to another app or my home screen?"
Since those cues are missing, people have to either remember their previous navigational history as a mental map (unnecessary cognitive load!) or they simply won't know what is going to happen if the tap the button, resulting in fear of doing something potentially wrong.
...
Here's my proposal
Okay, now let's stop criticizing the current implementation, since we all know it's easy to criticize but way harder to come up with better solutions. I tried my best though and came up with a different approach to navigating the Android OS. It's in a form of a video mockup and you can watch it enclosed to this post. Please read my annotations in this video.
I'm using this very kind of navigation - sans the visualization, of course - since I got my Nexus 4 over a year ago, using an app called GMD Gestures while hiding the navigation bar.
And well, it's a blast. It's way faster, ergonomic and simply better than any other current solution available right now - like, for instance the "pie navigation" implemented in some ROMs, which has some major interference with existing apps. I'd like to ask you to try it out yourself using GMD Gestures. After a day you won't go back to the standard navigation bar, I promise.
To wrap it up, here's a short list of pros and con of my proposal:
Pros:
+ coherently visualized, making it more graspable compared to other solutions
+ again, more ergonomic than the standard implementation
+ apps are always fullscreen and there's no need to swipe the navigation bar up when needed
+ 99% software based - only a tiny physical or visual cue must be added to the hardware itself to mark the start area of the gestures
+ conception-wise it integrates nicely into the idea of the beloved card-style apps like Google Now, G+,...
+ only very minor interference to current apps
+ adapts nicely to the various requirements of differently skilled users (see video annotations)
Con:
- small learning curve, like with all gestures, but you guys have never been too afraid of that, right?
...
It'd be really cool to hear back from you guys and pals just to let me know what you think. Thanks for reading and watching my stuff and I wish you
Merry Christmas and a Happy New Year,
Marc
Click to expand...
Click to collapse
Picked that one up on G+ and I think he might be on something. You may check out the comments here.

Amazing concept!!! I would love to see this implemented in a rom. The only problem is the learning curve for regular users.

Great!
Just great!! :good:

Learning curve too steep. This is good for "power users" but not for everyone.

What is your favourite screen size?

Assuming all specs, including price, would be the same (except for display size and battery), what is your favourite screen size? You can also assume 100% screen to body ratio. You can also assume battery life too would be the same, irrespective of the size.
Although larger screen sizes are preferred for media consumption, ease of use, pocketability, etc. also have a great impact in decision making.

This poll makes no sense to me.
The size of the screen does not matter as the interface cannot be adjusted to suit your preferences.
It happens that after increasing the letter size to max and adjusting the size of the desktop, the appearance of the application diverges.
With huge screens with high pixel density, the problem increases.
Therefore, when choosing a phone, check the design before paying for the purchase, so that there is no disappointment.