On Jan 10, 2008 11:38 PM, Bin Chen [EMAIL PROTECTED] wrote:
[...]
Ok, let me make the things clear, the content in a gdk window includes
many widgets, such as label, entry, button. But from the perspective of
X server, this widgets are just bitmaps with the states updated by GTK+,
right?
A
Hi,
ext Bin Chen wrote:
I am not doing very detailed profiling against this, but by comparing
the frame rate in my player against using pure framebuffer
implementation. The performance difference is large. If not using
shared memory to transfer the decoded image data, obviously the
On Jan 11, 2008 10:13 PM, Tristan Van Berkom [EMAIL PROTECTED] wrote:
On Jan 11, 2008 12:03 PM, Bin Chen [EMAIL PROTECTED] wrote:
[...]
Thanks for your reply, but I wonder how the Xlib or GDK knows the
image is drawing in a shared memory segment? In detail can you show me
some pseudo
On Jan 11, 2008 12:03 PM, Bin Chen [EMAIL PROTECTED] wrote:
[...]
Thanks for your reply, but I wonder how the Xlib or GDK knows the
image is drawing in a shared memory segment? In detail can you show me
some pseudo code to how to do it?
Well Gdk does know because it created the backing
On Jan 11, 2008 9:54 PM, Tristan Van Berkom [EMAIL PROTECTED] wrote:
On Jan 10, 2008 11:38 PM, Bin Chen [EMAIL PROTECTED] wrote:
[...]
Ok, let me make the things clear, the content in a gdk window includes
many widgets, such as label, entry, button. But from the perspective of
X server,
On Jan 11, 2008 11:46 PM, Eero Tamminen [EMAIL PROTECTED] wrote:
Hi,
ext Bin Chen wrote:
ext Bin Chen wrote:
I am not doing very detailed profiling against this, but by comparing
the frame rate in my player against using pure framebuffer
implementation. The performance difference is
On Jan 11, 2008 11:01 PM, Bin Chen [EMAIL PROTECTED] wrote:
Gdk does all image operations in 32-bits, N800/N810 display is 16-bit.
Whether you use SHM or not can be of less concern than this from the
performance point of view.
OK, so your point is because the convert process must be done
On Jan 12, 2008 9:46 AM, Tristan Van Berkom [EMAIL PROTECTED] wrote:
On Jan 11, 2008 11:01 PM, Bin Chen [EMAIL PROTECTED] wrote:
Gdk does all image operations in 32-bits, N800/N810 display is 16-bit.
Whether you use SHM or not can be of less concern than this from the
performance point
Hello,
I am running GTK+ in a singal machine, the machine is slow so I want
make GTK+ use XSHM extension to accelerate the drawing speed.
By taking a look at both GTK+ source code and the MIT-SHM paper, my
conclusion is :
1) The XSHM can only support XImage and Pixmap.
2) The GTK+ engine update
On Jan 10, 2008 4:26 PM, Tapani Pälli [EMAIL PROTECTED] wrote:
Hello;
ext Bin Chen wrote:
Hello,
I am running GTK+ in a singal machine, the machine is slow so I want
make GTK+ use XSHM extension to accelerate the drawing speed.
By taking a look at both GTK+ source code and the
Hello;
ext Bin Chen wrote:
Hello,
I am running GTK+ in a singal machine, the machine is slow so I want
make GTK+ use XSHM extension to accelerate the drawing speed.
By taking a look at both GTK+ source code and the MIT-SHM paper, my
conclusion is :
1) The XSHM can only support XImage and
Hello;
ext Bin Chen wrote:
On Jan 10, 2008 4:26 PM, Tapani Pälli [EMAIL PROTECTED] wrote:
Hello;
ext Bin Chen wrote:
Hello,
I am running GTK+ in a singal machine, the machine is slow so I want
make GTK+ use XSHM extension to accelerate the drawing speed.
By taking a look at
On Thu, 2008-01-10 at 16:50 +0800, Bin Chen wrote:
The GTK+ can draw pixbuf and image to the drawable, is there any
existing method for me to choose to force the low level gdk to use SHM
extension?
if the Xshm extension is available at compile time, gtk+ will use it;
there's no need to force
在 2008-01-10四的 17:40 +0200，Eero Tamminen写道：
Hi,
ext Bin Chen wrote:
I am not doing very detailed profiling against this, but by comparing
the frame rate in my player against using pure framebuffer
implementation. The performance difference is large. If not using
shared memory to
14 matches
Mail list logo
