| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #769
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Plastic: CPU load and redrawing bug on XP |
|---|
| Version: | 1.1-current |
|---|
| Created By: | Portale |
|---|
| Assigned To: | mike |
|---|
| Fix Version: | 1.1-current (SVN: v4244) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | Portale
15:14 Mar 20, 2005 |
| As stated in different threads in the fltk groups, there are redrawing bugs with the plastic scheme on Windows XP SP2.
I can reproduce it on Win XP Home SP2 with an ATI card, only if Fl_Window is used and not Fl_Double_Window.
The redrawing bug appears when another window is dragged around over the FLTK app. The CPU load rises very high and the app seems not to have the time to paint everything.
It seems as if the drawing of the background tiles uses so much CPU. If the plastic background tile is bigger, the CPU load goes down _and_ the redraw problems are reduced.
See the attached screenshot.
You can test it with the attached "tile.xpm" which is 128x128 pixels big (instead of the current 16x16 pixels).
Of course only making the tile bigger is not at all a fix for the redraw problems. But at least reduces the CPU load and mages resizing and makes resizing smoother.
And of course including the bigger xpm would make the executable 15 KB bigger. Maybe it would be good to assemble a bigger tile at program start, for example in "Fl::reload_scheme()".
Any thoughts? | |
| |
| #2 | Portale
14:31 Mar 21, 2005 |
| Status on Mac OSX:
Resizable windows with plastic scheme resize very slowly on the mac. But (of course) they don't have redraw problems.
Using a bigger tile.xpm boosts the speed and it is very smooth! Try it out! You will like it as much as Apples brushed metal ;) | |
| |
| #3 | mike
19:57 Mar 22, 2005 |
|
I've committed a 64x64 tile image (128x128 is a little too big for a toolkit that claims to be lightweight...).
| |
| |
| #4 | mike
13:03 Mar 25, 2005 |
| Fixed in Subversion repository.
OK, I've tested the current subversion repo code on my XP SP2 system and I don't get the redraw errors. Can you confirm?
| |
| |
| #5 | Portale
12:23 Mar 28, 2005 |
| > Fixed in Subversion repository.
> OK, I've tested the current subversion repo code on my XP SP2
> system and I don't get the redraw errors. Can you confirm?
I can confirm that with the bigger tile.xpm (64x64), the cpu load is reduced and the amount of redraw problems is smaller. Only with 128x128
pixels it totally disappears on my 2.66 GHz machine.
However, the redraw bug is still there, and will for sure occure more often on slower machines.
Did you do more than create a bigger tile.xpm?
On screenshot http://www.fltk.org/strfiles/769/plastic_redraw_bug_03.png I moved winamp from the upper right to the lower left across the demo app. Some damages were just not noticed by fltk or skipped, the winamp window reamains painted, there. (This binary was still compiled with the 16x16 tile.xpm)
If someone is interested to send me a patch that does some logging in order to find if, where and why something may be skipped, I'd like to help. | |
| |
| #6 | mike
12:55 Mar 28, 2005 |
|
Can you try testing with the "Windows Classic" theme selected from the Display control panel?
| |
| |
| #7 | Portale
13:16 Mar 28, 2005 |
| > Can you try testing with the "Windows Classic" theme
> selected from the Display control panel?
That's it!
Switching to the classic theme removes the errors totally.
For fun, I tested it with a 4x4 pixel tile.xpm: With the classic theme, the app is quite busy with redrawing, but 0 errors. With the modern theme, nothing but redraw errors. | |
| |
| #8 | Portale
16:13 Apr 07, 2005 |
| The bug doesn't occur anymore since rev. 4244
http://www.fltk.org/newsgroups.php?gfltk.development+v:2207 | |
| |
| #9 | mike
08:10 Apr 08, 2005 |
| Fixed in Subversion repository.
| |
[ Return to Bugs & Features ]
|
| |
