[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XForms] Canvas / button interaction

From: Clive Stubbings
Subject: Re: [XForms] Canvas / button interaction
Date: Mon, 13 Feb 2012 23:09:32 +0000 (GMT)


I think I can now describe whats happening, and can see a possible "solution" (ok, bodge), but as yet I don't understand why it happens.

The problem is specific to some classes of X-object. That includes at least filled polygons but there may be others. It does not apply to XLine.

When the object is rendered on the display, if the _CLIP_ region includes a canvas window the drawing stops at that point. It is not the actual object that you are drawing that matters, it seems to be the clip area.

In xforms, the clip area is set to the whole window, so in my case if the canvas is higher on the main window than the checkbutton, the check button wont get filled as a result of a mouse click, but will from an expose event because thats drawn using a different X function..

If I change the clip area to not include the canvas, then it looks like the polygon will get filled ok. So in terms of a software "solution", the answer seems to be to set the clip area to be just the object being displayed.

I might argue that this may be a good thing to do anyway, however with regard to this problem, this is not getting to the root-cause, so its a bodge.

I really can't see why this happens, particularly since its OK on one system (X-display) and not on another. I also don't understand why its only me that has seen this. So, at this point I cant even say if its an xforms bug, an Arch bug, an X.org bug or an X.org intel driver bug.

I have patched my library and will test it for a while, but at a first look, it seems to work for me. However I'll sit on the patch until someone else sees the problem and we can try to work out whats really happening..


On Sat, 11 Feb 2012, Clive Stubbings wrote:


Getting closer..

I changed the code so it paints the 'yellow' button as being the full size of the window (ie 300x200)..

Clicking the button, I get a strip 10 pixels high at the top of the window. So I moved the canvas from (10,10) to (10,25)... And I get a strip 25 pixels high...

So somewhere the the polygon fill is being clipped to the top edge of the canvas. Can't see it at the momet though.

If I create 2 canvases, its the top one that sets the limit - order doesn't seem to matter.


On Sat, 11 Feb 2012, Clive Stubbings wrote:


I've been having a bit more look at windows.

What seems to happen is:

        A main form window (id 1e00018) is created
        GC get created on that
        Then a pixmap is created (id 1e0003a)
        The pixmap is used for some initial drawing of the objects
        The canvas is created with a window (id 1e0003b)
        some more drawing happens on the pixmap
        the pixmap gets copied to the display

        A click event on the checkbutton does its
        object drawing on the original (id 1e00018) window

        An expose seems to go via the pixmap.

There may be something unstable here too. I'm sure that in the past an expose event anywhere on the form was enough to cause the objects to be re-drawn. However in my current build, which has -g enabled and some debug messages, thats not true any more - expose the button and its displayed, but the expose region has to include the object..

Basically at the moment it seems to copy a pixmap to 1e00018 but not draw a polygon on it....

XCopyArea( flx->display, p->pixmap, p->win, flx->gc, 0, 0, p->w, p->h, p->x, p->y );


XFillPolygon( flx->display, flx->win, flx->gc, xp, n, Nonconvex, CoordModeOrigin );



On Fri, 10 Feb 2012, Jens Thoms Toerring wrote:

Hi Clive,

On Fri, Feb 10, 2012 at 01:37:46AM +0000, Clive Stubbings wrote:
More bits of data..

Adding XFlush() and XSync() calls after the polygon draw makes no difference.

A redraw as a result of an expose event - eg window raise does
result in correct drawing.

Interestingly, it can be any part of the window that is exposed - it
doesn't have to be the bit with the button in it, or the bit with the

Two things that are different in the 2 cases are the clipping calls and
the value of flx->win, but it looks like they are not the problem.

Mmm, the different flx->win values worry me a bit. can there
something be going wrong with double buffering?

Jens, any idea how to fake an expose event in Xforms? I'd like to
see if what makes the difference is a real X-expose event or whether
its something different in the xforms handling of expose vs draw.

I guess you could use fl_XPutBackEvent() to stick an arti-
ficially created event into XForms' event queue...

                              Best regards, Jens
 \   Jens Thoms Toerring  ________      address@hidden
  \_______________________________      http://toerring.de

reply via email to

[Prev in Thread] Current Thread [Next in Thread]