Re: [XForms] Canvas / button interaction

[Clive Stubbings]

Hi,

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..

Cheers
Clive


On Sat, 11 Feb 2012, Clive Stubbings wrote:

> Ok,
>
> 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.
>
> Cheers
> Clive
>
> On Sat, 11 Feb 2012, Clive Stubbings wrote:
>
> > Jens,
> >
> > 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 );
> >
> > vs
> >
> > XFillPolygon( flx->display, flx->win, flx->gc, xp, n, Nonconvex, 
> > CoordModeOrigin );
> >
> > Odd..
> >
> > Cheers
> > Clive
> >
> > 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
> > > > canvas..
> > > >
> > > > 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