Re: Vrooom

[Owen Taylor <otaylor redhat com>]

[ sending again to the list with a bit of expansion ]

Sven Neumann <sven gimp org> writes:

> Hi,
> 
> Owen Taylor <otaylor redhat com> writes:
> 
> > I'm about to commit the attached (quite large) patch. It's all about
> > accelerating alpha compositing of images with and without the RENDER
> > extension, though it has random bug fixes scattered in it.
> 
> nice. Now if we could change GdkPixbuf to hold the data as ARGB
> instead of the stupid RGBA format, compositing pixbufs could become
> really efficient.  No hardware that I know of supports RGBA surfaces.

 a) This is why I made the accelerated operation "draw_pixbuf" -
    the GdkPixbuf structure has a nice GdkColorspace field
    where we can add GDK_COLORSPACE_NATIVE_ARGB or
    whatever.

    (It's a bit awkward for naming that COLORSPACE_RGBA means 
    big endian RGBA)

    No, we can't change the default :-), especially not now, it would 
    break all sorts of code which assumes the format of
    GdkPixbuf data.

 b) It actually doesn't matter significantly for RENDER right
    now; there is no way you can avoid copying the data once (into 
    a ShmPixmap, say), and on my machine I can copy data at 51 
    megapixels/s and copy, premutiply and convert to ARGB
    at 47 megapixels/s.

    Other machines may not have quite this high cpu/bus ratio,
    but they will soon enough with current trends.

    The same basic thing is going to hold true for other
    windowing systems, unless you can point the video
    card directly at the client data and tell it to get
    it, which is unlikely to ever be a safe or convenient
    API.

    The main reason for switching to premultipied ARGB would
    be client/server side consistency, and the fact that
    compositing _onto_ non-premultiplied RGBA is inherently
    rather slow and error prone.

Regards,
                                        Owen