home bbs files messages ]

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