| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
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 |
|---|
| Version: | 1.1.7 |
|---|
| Created By: | djl |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1-current (SVN: v5629) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
| |
| #1 | ianmacarthur
11:24 Nov 29, 2006 |
| tabs.cxx
6k | |
Trouble Report Comments:
| |
| 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!
--
Ian | |
| |
| 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. | |
[ Return to Bugs & Features ]
|
| |
