qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 7/9] fbdev: move to pixman
Date: Thu, 20 Sep 2012 08:16:41 +0200	[thread overview]
Message-ID: <505AB4C9.9070809@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1209191429510.29232@kaball.uk.xensource.com>

  Hi,

>> +        if (surface) {
>> +            pixman_image_unref(surface);
>>          }
>> +        surface = pixman_from_displaystate(ds);
> 
> Am I reading this right? Are you creating a new pixman surface in every
> call to fbdev_update?

No.  The whole block doing this is wrapped into "if (resize_screen)"
(which you don't see in the patch due to context being too small).

>> @@ -916,6 +953,10 @@ static void fbdev_refresh(DisplayState *ds)
>>      if (redraw_screen) {
>>          fbdev_update(ds, 0, 0, 0, 0);
>>      }
>> +
>> +    if (pixman_region_not_empty(&dirty)) {
>> +        fbdev_render(ds);
>> +    }
> 
> Why are you using fbdev_refresh for rendering instead of fbdev_update?
> From consistency with sdl and vnc as well as the semantics of these
> callbacks I think it would be better to do the rendering from
> fbdev_update and just call vga_hw_update here.

It _does_ call vga_hw_update.  The fbdev_update callbacks triggered by
this collect the updated regions in the dirty variable.  Finally we'll
render everything in one go (assuming we got any updates).

Performs better than doing the rendering in the fbdev_update callback.

> Pixman or non-pixman, I still think that this could benefit from
> implementing a DisplayAllocator interface: it would avoid a memcpy
> whenever there is no need for scaling and pixel conversions.

There is one more issue I didn't mention yet:  The framebuffer memory
should better be treaded as write-only memory as this is what gfx cards
are optimized for.  Read access works of course, but can be _very_ slow
depending on the hardware.

So implementing a DisplayAllocator and thereby making the vga emulation
operate directly on framebuffer memory is a very bad idea IMO.  Most
likely it will make certain operations (like cirrus bitblits) slower
even though it saves a memcpy.

cheers,
  Gerd

  reply	other threads:[~2012-09-20  6:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-19 11:15 [Qemu-devel] [PATCH v4 0/9] linux framebuffer display driver Gerd Hoffmann
2012-09-19 11:15 ` [Qemu-devel] [PATCH 1/9] QLIST-ify display change listeners Gerd Hoffmann
2012-09-19 11:15 ` [Qemu-devel] [PATCH 2/9] add unregister_displaychangelistener Gerd Hoffmann
2012-09-19 11:15 ` [Qemu-devel] [PATCH 3/9] move set_mouse + cursor_define callbacks Gerd Hoffmann
2012-09-19 11:15 ` [Qemu-devel] [PATCH 4/9] fbdev: add linux framebuffer display driver Gerd Hoffmann
2012-09-19 18:09   ` Stefano Stabellini
2012-09-21 12:28     ` Gerd Hoffmann
2012-09-24 11:06       ` Stefano Stabellini
2012-09-24 13:09         ` Gerd Hoffmann
2012-09-19 11:15 ` [Qemu-devel] [PATCH 5/9] fbdev: add monitor command to enable/disable Gerd Hoffmann
2012-09-19 11:15 ` [Qemu-devel] [PATCH 6/9] fbdev: make configurable at compile time Gerd Hoffmann
2012-09-19 11:15 ` [Qemu-devel] [PATCH 7/9] fbdev: move to pixman Gerd Hoffmann
2012-09-19 18:10   ` Stefano Stabellini
2012-09-20  6:16     ` Gerd Hoffmann [this message]
2012-09-20 11:33       ` Stefano Stabellini
2012-09-20 13:51         ` Gerd Hoffmann
2012-09-20 15:20           ` Stefano Stabellini
2012-09-20 15:27             ` Gerd Hoffmann
2012-09-20 15:28               ` Stefano Stabellini
2012-09-20 15:33                 ` Stefano Stabellini
2012-09-21  5:40                   ` Gerd Hoffmann
2012-09-21 10:48                     ` Stefano Stabellini
2012-09-19 11:15 ` [Qemu-devel] [PATCH 8/9] fbdev: add mouse pointer support Gerd Hoffmann
2012-09-19 11:15 ` [Qemu-devel] [PATCH 9/9] fbdev: add display scaling support Gerd Hoffmann
  -- strict thread matches above, loose matches on Subject: below --
2012-09-18  7:17 [Qemu-devel] [PULL 0/9] linux framebuffer display driver Gerd Hoffmann
2012-09-18  7:17 ` [Qemu-devel] [PATCH 7/9] fbdev: move to pixman Gerd Hoffmann
2012-09-18 15:01   ` Stefano Stabellini
2012-09-19  5:51     ` Gerd Hoffmann
2012-09-18 19:14   ` Anthony Liguori
2012-09-18 21:08     ` Anthony Liguori
2012-11-26 18:42     ` Alexander Graf
2012-11-26 20:01       ` Gerd Hoffmann
2012-11-26 20:05         ` Alexander Graf
2012-09-18 20:30   ` Søren Sandmann
2012-09-19  5:56     ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=505AB4C9.9070809@redhat.com \
    --to=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@eu.citrix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).