Copy Window to Pixbuffer - Xwindows

This is a discussion on Copy Window to Pixbuffer - Xwindows ; I started playing around with Xlib just to learn the basic functions that toolkits like GTK and Qt provide. I can draw a window anywhere on the screen in any color with any border width and color, write text, draw ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Copy Window to Pixbuffer

  1. Copy Window to Pixbuffer

    I started playing around with Xlib just to learn the basic functions that
    toolkits like GTK and Qt provide.

    I can draw a window anywhere on the screen in any color with any border
    width and color, write text, draw lines, good times. Now I'm learning how to
    write handler functions for XEvents.

    I'm working on the Expose event right now. I've read that the best/fastest
    way is to copy a window to a pix buffer and then redraw directly from there.
    I'm still learning all the Xlib calls. Can anyone tell me how to grab the
    contents of a window?

    Do you grab text and icons seperately, or just read pixel by pixel? Do you
    only use this on the background and images and then redraw the widgets, or
    does this work for all?

    Thanks!
    --

    Tom Bitsky, Jr
    tbj@automateddesign.com

    Automated Design Corporation
    P: (630) 783-1150 F: (630) 783-1159



  2. Re: Copy Window to Pixbuffer

    You typically want it the other way around when you're double buffering. Do
    all your drawing on the pixmap, and then copy the appropriate parts of the
    pixmap to the widget when it receives the expose event.

    The primary issue with double buffering like this is that you'll have to
    handle the case where the widget resizes, thereby requiring your pixmap
    resize accordingly.

    Thomas Junior wrote:

    > I'm working on the Expose event right now. I've read that the best/fastest
    > way is to copy a window to a pix buffer and then redraw directly from
    > there. I'm still learning all the Xlib calls. Can anyone tell me how to
    > grab the contents of a window?



  3. Re: Copy Window to Pixbuffer

    In comp.windows.x, Thomas Junior

    wrote
    on Fri, 07 Nov 2003 15:14:24 GMT
    :
    > I started playing around with Xlib just to learn the basic functions that
    > toolkits like GTK and Qt provide.
    >
    > I can draw a window anywhere on the screen in any color with any border
    > width and color, write text, draw lines, good times. Now I'm learning how to
    > write handler functions for XEvents.
    >
    > I'm working on the Expose event right now. I've read that the best/fastest
    > way is to copy a window to a pix buffer and then redraw directly from there.
    > I'm still learning all the Xlib calls. Can anyone tell me how to grab the
    > contents of a window?


    XCopyArea() will do this, but there are issues; for
    example, the window may be partly covered by another
    window. XCopyArea() will grab whatever the contents are in
    the rectangle the window describes, which may not be what
    you want. Note that XCopyArea() can also take a Pixmap
    source, which may be more in line with what you want, as
    another poster has already suggested; you can draw directly
    to the Pixmap then throw bits of the pixmap at the window.

    You can also use XGetImage(), if you want something you can manipulate
    on the client side, as opposed to the server side (the distinction
    becomes relevant if you use remote X clients, either via an SSH
    tunnel or directly using 'xhost +remotehostname'). XPutImage() is
    the reverse call, if you have a client-side image created
    using XCreateImage() already.

    >
    > Do you grab text and icons seperately, or just read
    > pixel by pixel? Do you only use this on the background
    > and images and then redraw the widgets, or does this work
    > for all?


    A window with subwindows will work with
    XCopyArea()/XGetImage(); the grab is essentially pixel
    by pixel, although far more efficiently implemented.
    Note that XPutImage() will not overwrite subwindows unless
    one changes XGCValues.subwindow_mode to IncludeInferiors
    (using XChangeGC()), which may lead to visual confusion if
    the subwindows decide to redraw themselves later and are unaware
    of this change. (If one wants to implement a "transparent
    input window" effect, best to set the background of the
    subwindow to be compatible with the background of the
    main window. I'd have to dig for the details, and programs
    implementing this visual effect are rare, AFAIK.)

    [.sigsnip]

    --
    #191, ewill3@earthlink.net
    It's still legal to go .sigless.

  4. Re: Copy Window to Pixbuffer

    So, the best solution seems to be to draw a full screen version to memory
    (pixmap), then display the "visible" contents based on the size of the
    window. Is there a more "memory efficient" manner?

    Thanks!
    Tom Junior




    "Thomas Junior" wrote in message
    news:kFOqb.14925$9M3.3848@newsread2.news.atl.earth link.net...
    > I started playing around with Xlib just to learn the basic functions that
    > toolkits like GTK and Qt provide.
    >
    > I can draw a window anywhere on the screen in any color with any border
    > width and color, write text, draw lines, good times. Now I'm learning how

    to
    > write handler functions for XEvents.
    >
    > I'm working on the Expose event right now. I've read that the best/fastest
    > way is to copy a window to a pix buffer and then redraw directly from

    there.
    > I'm still learning all the Xlib calls. Can anyone tell me how to grab the
    > contents of a window?
    >
    > Do you grab text and icons seperately, or just read pixel by pixel? Do

    you
    > only use this on the background and images and then redraw the widgets, or
    > does this work for all?
    >
    > Thanks!
    > --
    >
    > Tom Bitsky, Jr
    > tbj@automateddesign.com
    >
    > Automated Design Corporation
    > P: (630) 783-1150 F: (630) 783-1159
    >
    >




  5. Re: Copy Window to Pixbuffer

    Thomas Junior wrote:

    > So, the best solution seems to be to draw a full screen version to memory
    > (pixmap), then display the "visible" contents based on the size of the
    > window. Is there a more "memory efficient" manner?


    Not that's easy. There is at least one other way that I know of (I'm by no
    means an expert on X11 or an animation guru), but it's more complicated
    (and probably not worth the effort). When X sends an expose event with the
    area of the window to be repainted, you can create a pixmap of just the
    area to be drawn, render the scene to the mini-pixmap (translating the
    origin so that the resulting output gets clipped correctly on the pixmap),
    and then draw the mini pixmap on the area of the window to be exposed.
    It's messy, complicated, inefficient, and slow; but it uses only the amount
    of memory needed to render the exposed area flicker free.

    However, you're back to the original issue if your entire window needs to be
    redrawn. So it's a matter of picking your poison.


  6. Re: Copy Window to Pixbuffer

    Tony,

    You were a big help. Thank you very much.
    "Tony O'Bryan" wrote in message
    news:vr0aoeco108i47@corp.supernews.com...
    > Thomas Junior wrote:
    >
    > > So, the best solution seems to be to draw a full screen version to

    memory
    > > (pixmap), then display the "visible" contents based on the size of the
    > > window. Is there a more "memory efficient" manner?

    >
    > Not that's easy. There is at least one other way that I know of (I'm by

    no
    > means an expert on X11 or an animation guru), but it's more complicated
    > (and probably not worth the effort). When X sends an expose event with

    the
    > area of the window to be repainted, you can create a pixmap of just the
    > area to be drawn, render the scene to the mini-pixmap (translating the
    > origin so that the resulting output gets clipped correctly on the pixmap),
    > and then draw the mini pixmap on the area of the window to be exposed.
    > It's messy, complicated, inefficient, and slow; but it uses only the

    amount
    > of memory needed to render the exposed area flicker free.
    >
    > However, you're back to the original issue if your entire window needs to

    be
    > redrawn. So it's a matter of picking your poison.
    >




+ Reply to Thread