Re: Vrooom


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.

Salut, Sven

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]