[XForms] Canvas / button interaction

[Clive Stubbings]

I have recently been doing that dreaded periodic fork-lift linux update. It
always throws up some troublesome issues. This one is particularly wierd.

I have an old app, been working for years. Tried running it on a new system and
various bits of the gui didn't display right. It looked like a 'flush' issue
but fl_update_display() did not help.

However the issue shows up even if I run the old app on the old system but put
just the display over the network onto the new platform. New platform is Arch
Linux. Building against different libraries didn't change anything. The arch
xforms package is 1.0.94pre4-1, I was using something older..

I boiled it down to the example below. If the canvas object is created then the
checkbutton does not light when you press it. If the canvas object is not
created, the check button works fine. I believe that the object sees the mouse
button press because in the bigger app, I could see callbacks happening.

On my old system this works fine in both cases. So my take is this is an X
server interaction issue with a new Xorg. The X is X.Org X Server 1.11.4
Release Date: 2012-01-27, X Protocol Version 11, Revision 0.
Or am I missing something obvious.

Anyone got any ideas?

/*

If I build

gcc test1.c -lforms -o test1

the button works, but if I build

gcc -DCANVAS test1.c -lforms -o test1

It doesn't..

*/
#include <stdio.h>
#include <forms.h>

typedef struct {
FL_FORM *main;
void *vdata;
char *cdata;
long ldata;
FL_OBJECT *image;
FL_OBJECT *toggle;
} FD_main;


FD_main *create_form_main(void)
{
FL_OBJECT *obj;
FD_main *fdui = (FD_main *) fl_calloc(1, sizeof(*fdui));

fdui->main = fl_bgn_form(FL_NO_BOX, 300, 200);
obj = fl_add_box(FL_UP_BOX,0,0,1010,565,"");
#ifdef CANVAS
fdui->image = obj = fl_add_canvas(FL_NORMAL_CANVAS,10,10,80,50,"");
#endif
fdui->toggle = obj = fl_add_checkbutton(FL_PUSH_BUTTON,190,20,40,40,"Check");
fl_end_form();
fdui->main->fdui = fdui;
return fdui;
}

main(int argc, char *argv[])
{
FD_main *maingui;

fl_initialize(&argc, argv, "Test", NULL, 0);
maingui= create_form_main();
fl_show_form(maingui->main,FL_PLACE_POSITION,FL_FULLBORDER,"test");

while (1) {
fl_do_forms();
}
}



-----------------------
Cheers
Clive

[Paul]

Unable to reproduce the fault here, works fine with
Xorg 1.9.0, protocol version 11 rev 0. Sorry, haven't
got a later X to try it with.

Maybe check the options arch linux is using to start
Xorg - anything odd on its command line or config?

--
Paul Nicholson
--

[Jens Thoms Toerring]

Hi Clive,

On Thu, Feb 09, 2012 at 11:14:59AM +0000, Clive Stubbings wrote:
> I have recently been doing that dreaded periodic fork-lift linux
> update. It always throws up some troublesome issues. This one is
> particularly wierd.
>
> I have an old app, been working for years. Tried running it on a new
> system and various bits of the gui didn't display right. It looked
> like a 'flush' issue but fl_update_display() did not help.
> . However the issue shows up even if I run the old app on the old
> system but put just the display over the network onto the new
> platform. New platform is Arch Linux. Building against different
> libraries didn't change anything. The arch xforms package is
> 1.0.94pre4-1, I was using something older..
>
> I boiled it down to the example below. If the canvas object is
> created then the checkbutton does not light when you press it. If
> the canvas object is not created, the check button works fine. I
> believe that the object sees the mouse button press because in the
> bigger app, I could see callbacks happening.
>
> On my old system this works fine in both cases. So my take is this
> is an X server interaction issue with a new Xorg. The X is X.Org X
> Server 1.11.4
> Release Date: 2012-01-27, X Protocol Version 11, Revision 0.
> Or am I missing something obvious.

Not anything I could see - looks like an absolutely correct
program. Alas, I also can't reproduce it with a slightly
older XOrg version of 1.10.4. And a short look at the code
for drawing the checkbutton also doesn't show anything I
would consider to be strange. But the connection with the
existence of a canvas object is really "interesting". Might
be interesting to look if the draw_checkbutton() function in
checkbut.c is called at all. If it does the first thing I
would suspect is some clipping issues, otherwise something
really strange must be going on. Another thing that could
be interesting to check is if it makes a difference if one
swaps the creation of the canvas and the checkbutton in the
code...

Unfortunately, I won't be able to update to a newer XOrg
version at the moment, so I can't make promises when I will
be able to try to reproduce the problem on my machine.

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

[Ivan Powis]

... Just a thought, but I remember a similar issue under
similar circumstances occurring a while back. It even got to the
silly stage where with two systems seemingly running identical
software version numbers one would be OK, the other not.
Eventually tracked it down to the build rather than library
version numbers - on one the X server seemed to have been built
without (in this case if I remember correctly) the "Composite"
extension. I never went further into this, just rebuilt that
Xserver from source.

It may be worth checking that your new X server has all the
expected extensions built in (xdpyinfo) and/or that the card
driver supports them? Of course I've no idea which extensions
xforms would expect but ....

I'm sorry this is not a technically well informed response, but
its an idea for something else to check.

Ivan

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

[Clive Stubbings]

Hi Jens,

I had a bad feeling that you wouldn't be able to reproduce it. But at least I
know the code is sane and you haven't seen anything similar..

What I need to do is to pull the latest xforms source and build against that.
Then I can put some debug in the code to see if I can throw any more light on
whats happening.

I don't think its limited to just checkbuttons though. Other objects seemed to
be not quite right - eg some of the up/down shading wasn't always correct and I
had a button with an @> that didn't always fill the arrow. The checkbutton was
just the best (easiest to explain) example I could make.

I'll flip the canvas creation to happen later and see if that changes anything,
then pull the latest code and post an update.

Thanks
Clive

[Clive Stubbings]

Paul, Ivan,

Thanks for that. I'll take a more detailed look through the Xorg log later and
see if there are any clues. But thats a bit like looking for a needle in a
haystack....

Simple grep on the new system

(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) Loading extension DOUBLE-BUFFER
(II) Loading extension GLX
(II) Loading extension RECORD
(II) Loading extension XFree86-DRI
(II) Loading extension DRI2

The old system

(II) Loading extension DOUBLE-BUFFER
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension FontCache
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) Loading extension GLX
(II) Loading extension RECORD
(II) Loading extension XFree86-DRI


Jens, anything there ring any alarm bells?

Cheers
Clive

[Jens Thoms Toerring]

Hi Clive,

On Thu, Feb 09, 2012 at 02:03:48PM +0000, Clive Stubbings wrote:
> I had a bad feeling that you wouldn't be able to reproduce it. But
> at least I know the code is sane and you haven't seen anything
> similar..
>
> What I need to do is to pull the latest xforms source and build
> against that. Then I can put some debug in the code to see if I can
> throw any more light on whats happening.

That would be nice!

> I don't think its limited to just checkbuttons though. Other objects
> seemed to be not quite right - eg some of the up/down shading wasn't
> always correct and I had a button with an @> that didn't always fill
> the arrow. The checkbutton was just the best (easiest to explain)
> example I could make.

Wouldn't be unexpected if that would also happen with other
objects:-( But I still have no god iead at all what could be
the reasons...

> I'll flip the canvas creation to happen later and see if that
> changes anything, then pull the latest code and post an update.

I don't actulally expect it to make any difference, but if you
can do that it would at least show that the order of drawing
isn't involved - one thing that could play a role is "stacking"
of objects and that for some reasons their sizes aren't ca;cu-
lated correctly. It's rather unlikely but while we're still
groping in the dark any tiny bit of information can be helpful.

[Jens Thoms Toerring]

Hi Clive,

On Thu, Feb 09, 2012 at 03:08:25PM +0000, Clive Stubbings wrote:
> Thanks for that. I'll take a more detailed look through the Xorg log
> later and see if there are any clues. But thats a bit like looking
> for a needle in a haystack....
>
> Simple grep on the new system
>
> (II) Loading extension MIT-SCREEN-SAVER
> (II) Loading extension XFree86-VidModeExtension
> (II) Loading extension XFree86-DGA
> (II) Loading extension DPMS
> (II) Loading extension XVideo
> (II) Loading extension XVideo-MotionCompensation
> (II) Loading extension X-Resource
> (II) Loading extension DOUBLE-BUFFER
> (II) Loading extension GLX
> (II) Loading extension RECORD
> (II) Loading extension XFree86-DRI
> (II) Loading extension DRI2

Just for comparison purposes here's what I get:

(II) Loading extension GLX
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) Loading extension DOUBLE-BUFFER
(II) Loading extension RECORD
(II) Loading extension XFree86-DRI
(II) Loading extension DRI2

(II) Loading extension ATIFGLRXDRI
(II) Loading extension FGLRXEXTENSION
(II) Loading extension GLESX
(II) Loading extension AMDXVOPL
(II) Loading extension AMDXVBA

Looks more or less the same like as with your system,
just with a few additional ones probably for my AMD
Radeon graphics card.

[Ivan Powis]

I'm somewhat reluctant to press on with an extremely tentative
suggestion, since I've no evidence to indicate that this is the problem
here, but harking back to my own experience what you guys are listing
are the dynamically loaded server extensions. My original problem was
resolved by noting the compiled in extensions (or lack thereof). On my
current system:

(II) Initializing built-in extension Generic Event Extension
(II) Initializing built-in extension SHAPE
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension BIG-REQUESTS
(II) Initializing built-in extension SYNC
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-MISC
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing extension GLX

From memory, I'd somehow acquired a setup lacking the built-in Composite
extension, that also did not get loaded dynamically. No reason to think
that's specifically the problem here, but maybe its worth comparing the
built-in extensions too!

Ivan

[Clive Stubbings]

Hi Ivan,

Good point.. And since this is clearly 'X' related its not that tentative :-)

(II) Initializing built-in extension Generic Event Extension
(II) Initializing built-in extension SHAPE
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension BIG-REQUESTS
(II) Initializing built-in extension SYNC
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-MISC
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES

(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE

Though sadly with the exception of XFree86-Bigfont it looks like yours.

Cheers
Clive

[Clive Stubbings]

No change.

Added to xorg.conf and double checked the log

(**) Extension "Composite" is disabled

but I still also see

(II) Initializing built-in extension COMPOSITE

(II) UXA(0): Driver registered support for the following operations:
(II) solid
(II) copy
(II) composite (RENDER acceleration)
(II) put_image
(II) get_image

So I'm not sure how disabled it is!

Jens, FYI here is a call trace - it looks pretty sane.

wincheck=( flx->win == None || n <= 0 )

initialisation

fl_polygon(1,...,12) gc=0x827b760 wincheck=0
fl_polygon(1,...,15) gc=0x827b760 wincheck=0
draw_checkbutton(0x8278d58) ENTERorLEAVE 0
fl_drw_checkbox(..,194,28,23,23,11,..)
fl_polygon(1,...,11) gc=0x827b760 wincheck=0
fl_polygon(1,...,15) gc=0x827b760 wincheck=0
fl_polygon(1,...,14) gc=0x827b760 wincheck=0
fl_polygon(1,...,12) gc=0x827b760 wincheck=0
fl_polygon(1,...,13) gc=0x827b760 wincheck=0
handle_canvas(0x8278ef0,..)
fl_polygon(1,...,15) gc=0x827b760 wincheck=0
fl_polygon(1,...,12) gc=0x827b760 wincheck=0
handle_canvas(0x8278ef0,..)
fl_polygon(1,...,12) gc=0x827b760 wincheck=0
fl_polygon(1,...,15) gc=0x827b760 wincheck=0
draw_checkbutton(0x8278d58) ENTERorLEAVE 0
fl_drw_checkbox(..,194,28,23,23,11,..)
fl_polygon(1,...,11) gc=0x827b760 wincheck=0
fl_polygon(1,...,15) gc=0x827b760 wincheck=0
fl_polygon(1,...,14) gc=0x827b760 wincheck=0
fl_polygon(1,...,12) gc=0x827b760 wincheck=0
fl_polygon(1,...,13) gc=0x827b760 wincheck=0
handle_canvas(0x8278ef0,..)
fl_polygon(1,...,15) gc=0x827b760 wincheck=0
fl_polygon(1,...,12) gc=0x827b760 wincheck=0
handle_canvas(0x8278ef0,..)

mouse enter checkbutton

draw_checkbutton(0x8278d58) ENTERorLEAVE 1

left down

draw_checkbutton(0x8278d58) ENTERorLEAVE 0
fl_drw_checkbox(..,194,28,23,23,3,..)
fl_polygon(1,...,3) gc=0x827b760 wincheck=0
fl_polygon(1,...,12) gc=0x827b760 wincheck=0
fl_polygon(1,...,13) gc=0x827b760 wincheck=0
fl_polygon(1,...,15) gc=0x827b760 wincheck=0
fl_polygon(1,...,14) gc=0x827b760 wincheck=0

left up

draw_checkbutton(0x8278d58) ENTERorLEAVE 0
fl_drw_checkbox(..,194,28,23,23,3,..)
fl_polygon(1,...,3) gc=0x827b760 wincheck=0
fl_polygon(1,...,12) gc=0x827b760 wincheck=0
fl_polygon(1,...,13) gc=0x827b760 wincheck=0
fl_polygon(1,...,15) gc=0x827b760 wincheck=0
fl_polygon(1,...,14) gc=0x827b760 wincheck=0

leave

draw_checkbutton(0x8278d58) ENTERorLEAVE 1

If you keep clicking the colour values toggle as you would expect.

Cheers
Clive

On Thu, 9 Feb 2012, Paul Nicholson wrote:

>
> Maybe compositing is enabled and is getting in the way
> somehow. There's a page describing it here,
>
> https://wiki.archlinux.org/index.php/Composite
>
> Enabled by default. You could try disabling it and
> see what happens.
>
> We're all a bit stuck for suggestions, I guess it's
> just a case of trying things and fishing around for
> some handle on the problem.
> --
> Paul Nicholson
> --
>
>
>
>

[Clive Stubbings]

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.

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.

Cheers
Clive

[Jens Thoms Toerring]

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

[Clive Stubbings]

Hi Jens.

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

I was hoping to not involve the X event mechanism. I want to see if the
difference is in the xforms code or something to do with the state generated by
the exent handling.

Having thought about it a bit more, the window thing is niggling me too. I think
I need to dust off my old Xlib books..

Cheers
Clive

[Clive Stubbings]

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

[Clive Stubbings]

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

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