Re: Alpha-composition of two pixmaps
- From: "Dmitry M. Shatrov" <erdizz rambler ru>
- To: Michael L Torrie <torriem chem byu edu>
- Cc: gtk-list gnome org
- Subject: Re: Alpha-composition of two pixmaps
- Date: Thu, 28 Oct 2004 20:15:54 +0400
Michael L Torrie wrote:
On Thu, 2004-10-28 at 18:18 +0400, Dmitry M. Shatrov wrote:
GdkPixbuf is not what I need, cus it is by definition slow. I guess,
drawing pixbufs is optimized for Render just because it is frequently
used (all icons, for example), and alpha-drawable-to-drawable is too
special to even bother about it.
It's not slow by definition. Anyway it does use render directly. So if
you have an accelerated render driver in the X server, it will be plenty
fast. If not, then it will be slow even if you called render directly.
Well, being more correct, it's not fast enough (I realize, it does what
it is intended to do -- pixel format abstraction -- pretty effectively).
As I see XShm and XRender bits in gdk_draw_pixbuf, maybe it is its pixel
transformation that is too much overhead for my particular application:
there is a pair of non-filled wire-images, and only pixels covered by
several thin lines need transformation. To have more freedom, I'm using
GdkImage and work with pixel formats directly, and in combination with
XShm this provides good performance even for 1280x1024 fullscreen.
Looks like it worths adding a pair of calls to gdk-x11 and post it to
gtk-devel..
I don't think Render should be exposed in gdk. For one it's just a
backend method, and is not available on all platforms nor is it
available on all X servers.
Don't you mean all XOrg >R6.8 window composition bits are not for gdk as
well?
E. g. I'm dreaming about non-rectangular gnome-panel. Just imagine, a
sector in you right-bottom corner with a nice small hide button in the
corner also :) Such things are becoming nearly real and can't be missed!
And among these extensions is XRender.
Well, maybe it's more correct to add something like "an extension" to
gdk? Is there a proper procedure for adding platform-specific stuff, too
special for general API but still highly important?
Dmitry
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]