STR #1520

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.1 ]

STR #1520

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Fl_Tabs unnecessarily redraw on mouse push
Created By:djl
Assigned To:matt
Fix Version:1.1-current (SVN: v5629)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 ianmacarthur
11:24 Nov 29, 2006
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 djl
06:33 Nov 29, 2006
It seems that if tab 1 is active and the user clicks tab 2, all widgets on tab 1 get completely redrawn (unnecessarily) before tab 2 is then shown.
I have observed this on MS WindowsXP and on my embedded (ARM) board running nano-X. It may not do it on my SUSE linux box but it is hard to tell because it is a fast machine.
You cannot see this effect on a double buffered window, but it does surely increase the redraw time which is critical to me on my slow embedded board.
The unwanted redraw happens the moment you push the mouse down. So when you push the mouse button down on the new tab, the old tab is redrawn at that point. When you the release the mouse button, the new tab is drawn.
#2 ianmacarthur
11:23 Nov 29, 2006
Yes, I can confirm that this effect is observable on win32 and OSX. I'll post a hacked up version of the standard tabs demo that prints to stdout when the tab's child widgets get drawn...

I initally thought it was something to do with the visible focus indication moving around, but testing suggests that is not the culprit.
I am currently stumped as to what is occurring - possibly something in the logic for ::push()???
#3 ianmacarthur
12:10 Nov 29, 2006
Well, what I think is... the handle method for FL_PUSH falls-through at about line 147, into the handle method for FL_DRAG and FL_RELEASE, and that seems to be where the extra redraw gets triggered.
It is not clear to me whether the fall-through is intended or not... I don't really get what is going on here!
#4 djl
02:10 Nov 30, 2006
Thanks for looking at that. I've inserted a return 0; as line 135 and it seems to have fixed it. I don't see any unwanted side effects so I will run with this hack...  
#5 matt
07:56 Jan 21, 2007
Fixed in Subversion repository.

Now only the tabs themsleves get redrawn. As a little bonus, they indicate now, which tab was clicked.
bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.