Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.mobile.android    |    Discussion about Android-based devices    |    236,147 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 236,068 of 236,147    |
|    Alan to Arno Welzel    |
|    Re: How to create a plain wallpaper/back    |
|    17 Feb 26 14:58:23    |
      From: nuh-uh@nope.com              On 2026-02-17 14:32, Arno Welzel wrote:       > Carlos E. R., 2026-02-17 13:44:       >       >> On 2026-02-17 12:54, Arno Welzel wrote:       >>> Carlos E. R., 2026-02-17 11:30:       >>>       >>> [...]       >>>> A solid colour, when selected in a computer, uses far less resources       >>>> than a picture, even if it is a solid colour picture. A solid colour       >>>> picture still has to be drawn pixel by pixel. No solid fill function!       >>>       >>> A solid color JPEG is very efficient - since JPEG does not store single       >>> pixels but the mathematical description how to construct the content. In       >>> the end, the device will also just draw a black rectangle, when you       >>> create JPEG with just black in it. There is no "pixel by pixel" in this       >>> case. PNG should also be very efficient in this case, even though it is       >>> lossless compression.       >>       >> It is still a picture, it has to be drawn pixel by picture. The CPU       >> doesn't know that all the pixels are the same colour.       >       > Wrong - the CPU *does* know that, since the compression algorithm tells       > the CPU "this is a big black rectangle".       Well first of all, the CPU never "knows" anything.              What matters is the way that the CODE is written to go from having a       file in storage to the data in the buffer set up to be what is displayed       on the devices screen; essentially, how the HUMANS who wrote it made it       work.              A JPEG of just black for my iPhone 16 at 2556x1179 can be pretty small       (as small as about 21KB)...              ...but once it's been put into a buffer to be used whenever the screen       redraws, well then it's going to be 2556*1179*24 bits of data (assuming       8 bits per colour for RGB. That's about 9MB.              And there is no way that the rendering routines are going to rerender       the initial compressed JPEG to reproduce each pixel every time the       screen needs to be redrawn.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca