Interesting refresh problem - Motif

This is a discussion on Interesting refresh problem - Motif ; Hi, This is my first post to this newsgroup. I'm experiencing a widget refresh problem that appears to have surfaced only recently with the application I work on. Also, the refresh problem affects one class of machines (class A), but ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Interesting refresh problem

  1. Interesting refresh problem

    Hi,

    This is my first post to this newsgroup.

    I'm experiencing a widget refresh problem that appears to have
    surfaced only recently with the application I work on. Also, the
    refresh problem affects one class of machines (class A), but not
    another class of machines (class B). This leads me to suspect a video
    hardware, driver, of library issue. But I don't know where to start.

    I can't see an option for attaching a picture, so I'll do my best to
    describe the situation. A basic window looks a bit like the generic
    Microsoft window: it has a titlebar button widget, and a smaller close
    button widget, at the top of the frame. When a window is selected for
    moving (hold left mouse button on the titlebar) the frame outline
    appears. If the window is moved down slightly, such that the top of
    the frame outline is moved over the window's close widget and then the
    move operation is finalized (release left mouse button) some of the
    frame outline is left visible in the widget. It looks like it's not
    completely erased. Usually it looks like a streak, somewhat thinner
    than the frame outline used during the move. If the window is obscured
    and then unobscured a full paint is done (I'm guessing) and the
    streaks are cleaned up. Also, if instead the window is moved upwards
    such that the bottom of the frame outline crosses the close widget and
    the move is finalized, then no streaks appear (perhaps a full redrawn
    is being done in this case).

    All windows are expressed in UIL and compiled to UID. The Motif
    Resource Manager is used to manage the windows. This behaviour seems
    to be below the application level (I can't find where expose events
    are handled for the affected widget).

    Details:
    [OS] RHEL4U4 2.6.9-42.EL
    [MOTIF] OpenMotif 2.1.31
    [Xll] X11R6
    [Video card] mix of Raptor 1100T and Matrox ATC (P650 PCI) cards.


  2. Re: Interesting refresh problem

    cantthinkofanickname wrote:
    > I can't see an option for attaching a picture

    Upload your screen shot to one of the many image sharing
    sites, and post a link to it.

    Which window manager / desktop environment are you using?
    Do you use open source driver or binary driver?
    Is this your only Linux setup or can you try it on
    other computers with different hw/sw combinations
    (other graphics cards, versions of Linux)?

    Best regards,

    Dušan Peterc
    http://www.arahne.si

  3. Re: Interesting refresh problem

    Some window snippets can be found at <http://img02.picoodle.com/img/
    img02/6/10/22/f_uploadm_7b8d968.png>

    > Which window manager / desktop environment are you using?


    This a legacy Air Traffic Control system. There doesn't appear to be a
    desktop environment (nothing like KDE, GNOME, etc.)

    > Do you use open source driver or binary driver?


    Vendor driver. More details:
    Matrox ATC: Summit_FX-Silver-MATROX-ATC--XB-2.4-9h (custom
    driver from XiG)
    XServer: /usr/X11R6/bin/Xaccel [2.4.0 (build 17) 3D Accelerated-X (tm)
    Display Server]

    > Is this your only Linux setup or can you try it on
    > other computers with different hw/sw combinations
    > (other graphics cards, versions of Linux)?


    As mentioned in the email, there is the class B machine that works
    fine.
    These have the following video card:

    01:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro NVS
    285] (rev a1)

    I'm told that apart from the video card Class-A and Class-B machines
    are identical.
    It's not looking good for the video card.

    However, this appears to be a relatively new problem. I don't know
    what's changed
    to cause this.

    Thanks,
    Jevon


  4. Re: Interesting refresh problem

    Test


  5. Re: Interesting refresh problem

    I have been digging through the application code. This is not a
    standard problem. The application implements its own window manager
    (it does not use the Motif manager like I thought) and handles *all*
    the window events. The problem will probably be here and related to
    video card in some way. I think I'm on my own.

    Thanks,
    Jevon.


  6. Re: Interesting refresh problem

    cantthinkofanickname wrote:
    > I have been digging through the application code. This is not a
    > standard problem. The application implements its own window manager
    > (it does not use the Motif manager like I thought) and handles *all*
    > the window events. The problem will probably be here and related to
    > video card in some way. I think I'm on my own.


    Yes, with a custom set-up like this, you really are.

    I can only give you one example of visual bug I am experiencing.
    On Linux, with nvidia cards, and nv open source driver,
    the GXinvert drawing mode is not implemented correctly.
    As I use invert for rubber bands and other quick feedback,
    it sometimes leaves garbage on the screen.
    The problem goes away if I install the non-open source binary
    nvidia driver.

    Good luck with bug hunting.

    Dušan Peterc
    http://www.arahne.si

  7. Re: Interesting refresh problem

    This is like what I'm seeing. The rubberband (rectangle) is drawn
    during the move operation. On the move finalize operation the
    rubberband is undrawn (XOR the rectangle). Here's the interesting bit.
    When I step through these operations in gdb it works fine; however, if
    I 'continue' through these operations then garbage is left behind.
    What you say is very helpful.

    Thanks,
    Jevon


  8. Re: Interesting refresh problem

    cantthinkofanickname wrote:
    > This is like what I'm seeing. The rubberband (rectangle) is drawn
    > during the move operation. On the move finalize operation the
    > rubberband is undrawn (XOR the rectangle). Here's the interesting bit.
    > When I step through these operations in gdb it works fine; however, if
    > I 'continue' through these operations then garbage is left behind.


    For these kind of XOR feedback to work correctly,
    it is quite important that your drawing area is not modified
    while the operation is going on.

    One possible scenario:
    1. start operation, xor the marked area
    2. an expose event, area is partially redrawn
    3. end operation, xor the marked area, garbage left behind.

    Alternatively, instead of expose, window manager could use
    backing store for transient windows (like menu),
    no event would be sent to your app,
    but results could be similar.

    As today's graphics cards and CPU are several orders of
    magnitude faster, it is quite feasible to drop the xor,
    and use a feedback method which permit double or partial
    redraws without anomalies.

    Best regards,

    Dušan Peterc
    http://www.arahne.si

  9. Re: Interesting refresh problem

    The scenario you describe is actually described in
    a comment by a previous developer. It was handled
    by a partial refresh of the window. The garbage I
    am seeing though seems to be something a little
    different.

    They (the developers) have really made a mess of
    this. The rubber-band code is insidious and pops
    up every where: any place where there is some kind
    of change in the window (cut+paste too).

    I'm about to give up. Like you say, I'll probably just
    force a refresh of the entire window.

    Thanks again for your help.
    Jevon


  10. Re: Interesting refresh problem

    Fixed!

    I lucked out. Actually, you gave me a clue.

    I made a guess and inserted an XSync()
    before the undraw. This fixed it. There must
    be some old X events floating around that
    interefere with the undraw; and specific to
    this kind of XServer.

    Hopefully I never have to look at this part of
    the code again.

    Thanks very much,
    Jevon


+ Reply to Thread