3 ms·

real question is how did X11 performance get so bad that the Pi feels so weak

swiley 11y ago
I've never used x11 on the pi but it seems like a lot of the memory is allocated as disk cache in the default distributions. Plus if you use a crappy/huge DM/WM it will feel sluggish even on a fast computer.
- spiralpolitik 11y ago
  Lack of memory seems to be the main issue I've hit with the Pi. Having the Graphics card use the system memory gives you the worst of both worlds with so little memory to begin with.
  - vardump 11y ago
    Raspberry Pi is a graphics card with a tiny ARM chip bolted onto it.
    - wolfgke 11y ago
      At the RPi 2, the CPU is not that tiny anymore.
  - jandrese 11y ago
    The problem is exacerbated on the 256MB models. IMHO those models have too little memory and are somewhat crippled right out of the box. Only the 512MB models are even somewhat reasonable.
simcop2387 11y ago
Because the Rpi doesn't have much in actual working acceleration for X, it's all CPU driven for drawing, and display. That's one reason for hoping the VC4 stuff gets into the 4.5 kernel, then the KMS driver and Gallium3d should be workable on the PIs allowing for a much saner X experience.
Lerc 11y ago
1152x900 8bit = 1,036,800 bytes on screen 1920x1080 24bit = 6,220,800 bytes on screen So for starters, a lot of people are trying to push around more, larger, pixels. Some years ago I did some experiments with the OLPC-XO essentially analysing this exact problem. Modern software on a platform weaker then current Entry-Level. Analysing the overhead in printing a terminal text to a screen, I found a process that output a great deal of text but >dev/null took 1.5 seconds and tried a couple of different terminals. 7 seconds using bitmapped fonts 30 seconds using xft 6 minutes 34 seconds using vte (Pango/Cairo) That's a lot of overhead. You get unicode, scalable fonts and extras but it all comes with a cost. Most of that cost isn't intrinsic to the additional capabilities, but just an accumulation of minor inefficiencies because the result was ok on the machines we were using at the time.
- lttlrck 11y ago
  Larger pixels?
  - deleted 11y ago
    [deleted]
  - ShinyCyril 11y ago
    As in more bits per-pixel.
  - bprieto 11y ago
    I think he meant larger in the sense that 24 bits is larger than 8 bits
ChuckMcM 11y ago
Well X11 in general was memory bandwidth hungry, but you drop down to 720p (closer to the 1154 x 900 size) and you get a bit better. Also if you could get the Pi to run with a black and white frame buffer it might help.

I've never used x11 on the pi but it seems like a lot of the memory is allocated as disk cache in the default distributions. Plus if you use a crappy/huge DM/WM it will feel sluggish even on a fast computer.

spiralpolitik 11y ago
Lack of memory seems to be the main issue I've hit with the Pi. Having the Graphics card use the system memory gives you the worst of both worlds with so little memory to begin with.
- vardump 11y ago
  Raspberry Pi is a graphics card with a tiny ARM chip bolted onto it.
  - wolfgke 11y ago
    At the RPi 2, the CPU is not that tiny anymore.
- jandrese 11y ago
  The problem is exacerbated on the 256MB models. IMHO those models have too little memory and are somewhat crippled right out of the box. Only the 512MB models are even somewhat reasonable.

simcop2387 11y ago

Because the Rpi doesn't have much in actual working acceleration for X, it's all CPU driven for drawing, and display. That's one reason for hoping the VC4 stuff gets into the 4.5 kernel, then the KMS driver and Gallium3d should be workable on the PIs allowing for a much saner X experience.

Lerc 11y ago

1152x900 8bit = 1,036,800 bytes on screen 1920x1080 24bit = 6,220,800 bytes on screen So for starters, a lot of people are trying to push around more, larger, pixels. Some years ago I did some experiments with the OLPC-XO essentially analysing this exact problem. Modern software on a platform weaker then current Entry-Level. Analysing the overhead in printing a terminal text to a screen, I found a process that output a great deal of text but >dev/null took 1.5 seconds and tried a couple of different terminals. 7 seconds using bitmapped fonts 30 seconds using xft 6 minutes 34 seconds using vte (Pango/Cairo) That's a lot of overhead. You get unicode, scalable fonts and extras but it all comes with a cost. Most of that cost isn't intrinsic to the additional capabilities, but just an accumulation of minor inefficiencies because the result was ok on the machines we were using at the time.

lttlrck 11y ago
Larger pixels?
- deleted 11y ago
  [deleted]
- ShinyCyril 11y ago
  As in more bits per-pixel.
- bprieto 11y ago
  I think he meant larger in the sense that 24 bits is larger than 8 bits

ChuckMcM 11y ago

Well X11 in general was memory bandwidth hungry, but you drop down to 720p (closer to the 1154 x 900 size) and you get a bit better. Also if you could get the Pi to run with a black and white frame buffer it might help.