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 of view. > > > > OK, so your point is because the convert process must be done on every > > operation, so the performance will be bad? But I think if the XSHM is > > used, at least the transfer overhead will be cut, right? > > What are you using to compose the image ? if you are doing direct > pixel operations on the permanent GdkImage that you created > and occasionally tell the X server to update a window based on > your shared image, this should be fast. > > Data transfers over unix sockets generally go: > while (not finished writing and no errors) > write (8kb chunks of remaining data); > > If you are using shared memory, then you still need to wake up > the X server process for it to copy the data internally in its own > process - unless these are really huge images, you are not > gaining much by using XSHM. > > Its really hard to say what will be optimal for your situation > without a little more context on what you want to achieve. > OK, from the thread above I have point out the main purpose of me to start this thread is I want to write a video player in a slow machine, I have tested the X and framebuffer case that the difference is large, so I am going to find the root cause so I can make the two results closer.
Thanks. Bin _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
