From: usenet@arnowelzel.de   
      
   Alan, 2026-02-17 23:58:   
      
   > 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.   
      
   Yes, I know. But I did not start with the term "the CPU doesn't know", I   
   just explained in in this way, so the original poster will understand it.   
      
   > A JPEG of just black for my iPhone 16 at 2556x1179 can be pretty small   
   > (as small as about 21KB)...   
      
   Yes - because the compression consists of not much more than "this is a   
   black rectangle" and not of thousands of individual pixels.   
      
   > ...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.   
      
   Which is nearly nothing compared to multiple gigabytes(!) of RAM   
   available in modern smartphones. A mobile SoC does this without any   
   major effort at all.   
      
      
   --   
   Arno Welzel   
   https://arnowelzel.de   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)