box_cursor leaves ghost frames on screen

[brandy125]

The box_cursor procedure leaves ghost frames on the screen while moving the mouse with a buttom pressed or while resizing the box.

GDL> window,xsize=500,ysize=500
GDL> box_cursor,100,100,100,100,/init

Anybody can confirm if this is on other OSs as well?

[GillesDuvert]

Yes this is due to the use of CAIRO by GTK, and wxWidgets uses GTK on linux. CAIRO is probably very modern and all that but does not, and will not, include XOR or INVERT graphic writing modes. See #1288. On OSX and Windows, no GTK, no CAIRO, no problem. Using X11 (gdl -X ) makes box_cursor work on linux, but on graphic windows only, not in WIDGET_DRAW. Yes this is nightmarish.

[brandy125]

Thank you for that hint with gdl -X Is there a way to use X11 temporarily inside a running GDL session (just for that box_cursor stuff)?

[GillesDuvert]

Ah, excellent question! At some point, (gdl 0.9.9 ?) this was possible, but to simplify maintainance of GDL, its now either X11 or wxWidgets. But, I found that replacing "6" (XOR) by "10" (Invert) in box_cursor.pro produced good results, especially on a black background. This could help you.

[GillesDuvert]

incidentally, I've patched GDL to use Invert when XOR (6) is used in procedures like box_cursors. helps a little.

[brandy125]

@GillesDuvert thanks for that but I noticed that at least on my setup the command

GDL>device,set_graphics_function=10

has no effect. Actually no value makes any difference while after starting GDL with -X it does:

bash$ gdl -X

GDL> px=[219,281,281,219,219]
GDL> py=[219,281,281,319,219]
GDL> window,xsize=500,ysize=500,xpos=100,ypos=500 & erase,20
GDL> plots,px,py,col=255,/dev
GDL> device, set_graphics = 6
GDL> plots,px,py,col=255,/dev
GDL> plots,px,py,col=255,/dev
GDL> plots,px,py,col=255,/dev
GDL> 

so after setting set_graphics_function to 6 it nicely makes the triangle disappearing and appearing.

When starting gdl without "-X" the triangle does not disappear even setting set_graphics_function to any value between 0 and 15.

Maybe only a problem with my setup?

[GillesDuvert]

I have changed the actual operation for '6' only for the wxWidgets 'flavour' of the window. Nothing for X has changed, as I believed the old X11 code to be OK. This to avoid changing the code in box_cursor, that should work "as is" and not with my proposed ugly patch.

I took for granted that the device, set_graphics=XX historical command for X11 windows produced excellent results, but as there are no test in our testsuite checking that, regression has occured. (OTOH, such a test will not pass with the default windows, that are wxWidgets.) Your test show that even the X11 flavor do not obey to the set_graphics_function command.

[brandy125]

Maybe I was not clear in my post. With X11 it is working nicely. When working with wxWidgets the set_graphics=XX has no effect.

[GillesDuvert]

Do you mean that either 1) you have compiled GDL with the https://github.com/gnudatalanguage/gdl/commit/86bd1917ce3cac695870af612a5a8dd282d7572f patch, and use a pristine box_cursor, or 2) you have just replaced '6' by '10' in the box_cursor.pro code, and found that box_cursor is still making clearly visible ghosts?

[brandy125]

I was playing only with the set_graphics inside the box_cursor in my previous posts.

Now I downloaded your patch and tried again with a pristine box_cursor and can confirm that with wxWidgets it does not work.

There are still (teh same) ghosts and the set_graphics_function inside the box_cursor (or in my examples) has absolutely no effect whatever value I put there. This parameter is simply ignored.

Is there anything else I can try?

On 6. Apr 2024, at 15:21, Giloo @.***> wrote:

Do you mean that either

you have compiled GDL with the 86bd191 https://github.com/gnudatalanguage/gdl/commit/86bd1917ce3cac695870af612a5a8dd282d7572f patch, and use a pristine box_cursor, or 2) you have just replaced '6' by '10' in the box_cursor.pro code, and found that box_cursor is still making clearly visible ghosts? — Reply to this email directly, view it on GitHub https://github.com/gnudatalanguage/gdl/issues/1797#issuecomment-2041158999, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOC5K6F4PIUG7FQ5M6KXG3LY4A4JNAVCNFSM6AAAAABFV4O63SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGE2TQOJZHE. You are receiving this because you authored the thread.

[GillesDuvert]

Hm strange, here with the latest patch and the untouched box_cursor.pro I have decent results whatever the background color. Are you on linux?

[brandy125]

Yes, linux, suse tumbleweed, latest with fvwm2

On 6. Apr 2024, at 18:42, Giloo @.***> wrote:

Hm strange, here with the latest patch and the untouched box_cursor.pro I have decent results whatever the background color. Are you on linux?

— Reply to this email directly, view it on GitHub https://github.com/gnudatalanguage/gdl/issues/1797#issuecomment-2041212316, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOC5K6FC4KFOCD3FAV7KJX3Y4BT3DAVCNFSM6AAAAABFV4O63SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGIYTEMZRGY. You are receiving this because you authored the thread.

[GillesDuvert]

Hm, this may depend from the version of either [cairo, gtk] (indirectly) or [wxWidgets] (directly) used by the plplot driver (easy is'nt it?). Here I have the plplot drivers depend on libwx_gtk3u_core-3.1.so.7. That said, I gave a look at the GDL code and wonder if there is not an added complication due to the double buffering used by wxWidgets and supposed to be faster.

[GillesDuvert]

1802 may be the solution.