Deep Color support

[Pekka Paalanen]

On Sun, 27 Apr 2014 14:45:44 +0200
Wolfgang Draxinger <wdraxinger.maillist at draxit.de> wrote:

> On Sun, 27 Apr 2014 13:57:45 +0200
> John Kåre Alsaker
> <john.kare.alsaker at gmail.com> wrote:
> 
> > We still are limited by both graphics memory and bandwidth.
> > A fullscreen 64bpp 4K client will use about 128 MB for the
> > framebuffer.
> 
> Indeed. OTOH clients not actively altering their contents and not
> being visible are getting their image data swapped out of
> graphics memory.

Do they, really? Or does it happen on-demand, slowly RAM<->VRAM,
causing hickups, a bit like traditional swapping RAM to disk?
Especially when re-exposing we'd likely get a jerk.

> Also if a client is invisible alltogether it's perfectly
> reasonable to discard it's backingstore alltogether (FBOs stay
> intact of course); this has been the behavior specified and also
> one of the reasons why I started experimenting with GBM to bypass
> display servers' backingstore managment. Of course this adds the
> cost of a full redraw at client re-expose.

Yes, the idea of discarding buffers when not needed has occurred,
but so far it has not been implemented in Wayland, we have no
protocol for it yet. It is a tough question on what to do when
trying to expose a window that had its buffer discarded, as we aim
for glitch-free, every frame is perfect -kind of user experience.

I believe, that no modification to Mesa EGL, that would cause
existing applications to suddenly start getting a 64-bit pixel
format unrequested, would be accepted. I suspect we would have lots
of angry users saying their favourite game has regressed in
performance, or people would start saying "Yeah, Wayland is so slow,
it's just crap with games." That's the last thing we'd want.


Thanks,
pq