Re: Vrooom

[Owen Taylor <otaylor redhat com>]

Sven Neumann <sven gimp org> writes:

> Hi,
> 
> Owen Taylor <otaylor redhat com> writes:
> 
> >  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.
> 
> I disagree. DirectFB has such an API that allows you to create
> DirectFB surfaces from preallocated data without copying the data.
> These surfaces are then handled by the surface manager and can 
> thus be loaded into the video RAM to be used by the video card 
> directly. Of course this only works if the data is never again
> accessed directly which is assured through a locking mechanism.
> 
> This would work well for stock pixbufs since they never go or
> change. If we could create stock pixbufs with ARGB data or make
> the GtkIconFactory store them as ARGB internally, blitting of 
> stock icons could be nicely accelerated and I guess this does 
> not only hold true for the DirectFB backend.

Couple of things going on here:

 - There is no _hardware_ reason that DirectFB couldn't
   support RGBA surfaces of this type; DirectFB has to
   copy the data into video memory, it could convert
   it at the same time, without significant performance
   loss. (I don't believe the "AGP Textures" mode of 
   operation makes sense since the surface would have
   to be in special memory. As long as the CPU is involved

 - To do this sort of thing, we'd have to either have change 
   tracking or an immutable flag on GdkPixbuf. We don't
   so it isn't an option for 2.0. (*)

 - I suspect that in general trying to guess when we should
   cache a "hardware surface" copy of a GdkPixbuf is a loosing
   proposition. The library or application is in a better
   place to do that, since it knows whether it expects
   to be drawing with a pixmap again.

   My feeling here is that the right way to go in the
   middle-term is to look at ARGB and RGB GdkVisuals that
   for X, don't actually correspond to Visuals, then
   we can easily have:
  
    GdkPixmap *gtk_stock_get_stock_item_pixmap (GdkScreen *screen,
                                                id, state, ...);

   Or it may be better to stick with the current system   
   until we redo the entire GDK rendering API. Even small
   additions are probably 2.4 fodder at this point.

Regards,
                                        Owen

(*) It would be _conceivable_ to add a private immutable
    flag that would be set for things like stock icons.
    But for local display, sending 10,000 48x48 stock
    icons to the video card / s is very reasonable. A typical
    screen display has maybe 20-30 24x24 stock icons.

    Networked display is the only place where this could
    be a big win, and even there I don't think it will matter
    significantly.