STR #3113: Fl_Table scrollbars misdraw after resize

STR #3113

Application:	FLTK Library
Status:	2 - Closed w/o Resolution
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	Fl_Table scrollbars misdraw after resize
Version:	1.3-current
Created By:	cand
Assigned To:	cand
Fix Version:	Will Not Fix
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	cand 00:14 Aug 01, 2014

bug.png
24k

Trouble Report Comments:

#1	cand 09:08 Jul 21, 2014

There are two drawing bugs in the current table scrollbars. Both seem to be caused by missing redraw() calls somewhere. 1. Build the table-sort example 2. Resize the window 3. Drag one of the scrollbars The scrollbar snaps back to position 0 when you let go of the mouse. When you force a redraw by covering the window, it's drawn in the correct position. Second: 1. Build table-sort 2. Click on the scrollbar buttons 70% of the time the button stays down after you no longer press the mouse button. When forced to redraw it is in the correct state.

#2	greg.ercolano 11:56 Jul 25, 2014

Thanks -- taking this one. Sounds as you say, probably with the resize() method.. I'll take look and follow up.

#3	greg.ercolano 12:09 Jul 25, 2014

Hmm, can't replicate either problem. Make sure you're using fltk 1.3.x current (as reported) by doing a clean checkout from SVN and rebuilding. If you still have the problem with a clean SVN, I guess I'd need to know more about your platform/distro/winmgr/X version as I can't replicate on Sci Linux 6.3 (pretty sure your platform is linux related). If this is with tinycore, perhaps give info on how to replicate your environment; I have some test machines here I can install different versions of linux on to test.

#4	cand 12:19 Jul 27, 2014

It is a clean r10173 checkout of fltk-1.3. JWM window manager (a non-compositing WM), Xorg server 1.9.5, x86_64 linux (LFS). Copying the same binary to Xubuntu 14.04 or current TC does not show it. Whether it's a missing redraw in the widget or an implicit refresh bug in that Xorg version to be determined.

#5	greg.ercolano 23:18 Jul 31, 2014

Just curious -- does it affect the problem if you change the Fl_Double_Window in the code to an Fl_Window instead? i.e. BEFORE: Fl_Double_Window win(900,500,"Table Sorting"); AFTER: Fl_Window win(900,500,"Table Sorting"); The behavior you describe sounds weird.. sure sounds like a stale buffer being shown, i.e. a double buffering bug of some kind. Also: curious if the test/scroll.cxx widget shows this behavior too if you change the Fl_Window -> Fl_Double_Window.

#6	cand 00:15 Aug 01, 2014

Yes, it does, see attached bug.png. When I change table-sort to use plain Fl_Window, my wallpaper shines through.

#7	cand 00:18 Aug 01, 2014

test/scroll works correctly both with a double window and a normal one. It's only Fl_Table as far as I can see.

#8	greg.ercolano 08:56 Aug 01, 2014

I installed jwm on a spare fedora14 machine and couldn't replicate the described behavior either. However, I did notice on this system all windows flickered quite a bit on resize under jwm. Especially when windows were resized *larger*, I think jwm is first drawing the area in black, then lets the window draw over that. This causes a large amount of flicker. Probably no double buffering in the graphics driver/hardware going on here.. this fedora14 box is an old HP box with mobo graphics chips that are probably very limited. The problem /might/ be in fltk code that only shows up on certain graphics hardware/window manager combos. (Or it could be a graphics driver issue) If you can try the tests in Comment #5, that'd perhaps narrow it down.

#9	cand 09:15 Aug 01, 2014

I did? See comments #5 and #6.

#10	cand 09:15 Aug 01, 2014

Sorry, 6 and 7.

#11	greg.ercolano 13:45 Aug 01, 2014

(Sorry, guess I was looking at a stale web page this morning when I posted comment #8) That image looks mighty strange. Very useful though. The fact the desktop shows through seems to me to indicate something is wrong at a very low level, since the window should have already drawn its entire background over the window, so there really shouldn't be a way for the desktop to show through even if Fl_Table didn't draw itself at all, I would think. One low level thing is XDBE. Try changing the state of XDBE when building FLTK. So if your builds so far have it enabled, disable it.. or if it's disabled, then enable it. e.g. ./configure --disable-xdbe ; make clean ; make cd examples ; make clean ; make

#12	cand 00:03 Aug 02, 2014

Toggling Xdbe did nothing. It was enabled by default, disabling it did not change table-sort behavior with either type of window.

#13	cand 00:15 Aug 02, 2014

It is caused by something in Fl_Table::draw, as if I put "Fl_Group::draw(); return;" as the first line, scrollbars draw properly. Bisecting, the faulty line seems to be // Explicitly draw border around widget, if any draw_box(box(), x(), y(), w(), h(), color()); Placing a return before this -> scrollbars draw properly. Placing a return right after this line -> bug.

#14	cand 00:20 Aug 02, 2014

Further, only the default scheme is affected. Forcing table-sort to gtk+ or plastic does not show the bug.

#15	greg.ercolano 09:26 Aug 02, 2014

Thanks, good info. Will see if I can figure it out. I'll probably follow up with some patches for you to try. Odd that draw_box() is somehow causing the desktop background to show through.

#16	greg.ercolano 13:43 Oct 27, 2014

I was unable to replicate and couldn't help determine the issue OP is having. Unassigning myself, as I've not the time currently to further investigate. If that changes, I'll re-assign myself. Meanwhile, other devs feel free to take this on.

#17	cand 07:04 Jul 22, 2015

Closing as this is very likely an X driver bug.