Re: [Qemu-devel] [PATCH 7/9] fbdev: move to pixman

[Gerd Hoffmann]

  Hi,

> It might be a good idea to get rid
> of DisplayAllocator altogether.

After some digging in the source code:  Yes, I think so.

Look, we have *two* concepts for avoiding memcpy:

The first is the DisplayAllocator.  Only implemented by SDL, which is
scheduled to be downgraded by anthonys gtk patches.  Doesn't really fit
into the concept of displaychangelisteners coming and going at runtime,
and also not of having multiple displaychangelisteners (like sdl+vnc at
the same time).  It allows vga emulation to render directly into a SDL
buffer.

The second is qemu_create_displaysurface_from().  It allows vga
emulation hand out a surface with direct pointer to the guests video
memory for displaychangelisteners to read from.

You can't have both (i.e. the guest will never ever write directly into
the SDL buffer), there will always be at least one memcpy.

So what happens in practice?

In any graphics mode relevant today vga emulation will use
qemu_create_displaysurface_from().  Whenever a DisplayAllocator is
present or not doesn't make any difference then.

In case vga emulation has to render something because the guests video
memory can't be represented directly as displaysurface (text mode, gfx
modes with <= 256 colors) it will allocate a surface where it will
render the screen to and will use the SDL DisplayAllocator if registered.

I somehow doubt text mode acceleration is worth the complexity+confusion
DisplayAllocator adds to the picture.

Also I'd like to have reference counting for display surfaces because I
can offload the display scaling to a separate thread then.  Guess this
is easier to implement when zapping DisplayAllocator first.

cheers,
  Gerd