| [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1438
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: | Mandelbrot demo not redrawing correctly |
Version: | 1.1-current |
Created By: | ianmacarthur |
Assigned To: | mike |
Fix Version: | 1.1-current (SVN: v5614) |
Fix Commit: | fbd01308b987713ed7487014f15abb99dd5ae2d2 |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | ianmacarthur 09:13 Sep 22, 2006 |
| Sorry - hit the wrong key... Here's what I was trying to say:
On my FC5 linux box, with 1.1-x 5479 from svn, I find that the Mandelbrot demo does not redraw correctly. To produce this fault, I open the Mandelbrot demo, then right-click to pop up a julia set window. Position this window so it overlaps (and damages, I assume) the mandelbrot window. Close the julia set window - the Mandelbrot window becomes black.
Left clicking in the window causes it to redraw and the mandelbrot re-appears.
The does not occur on my OSX box, so I guess it is linux specific - or possibly graphics driver specific? The box I test on has a Nvidia card and driver installed.
As a special bonus query - the Mandelbrot demo is *much* slower on the OSX box than on the FC5 box, but it's not clear why, since the OSX box is notionally higher spec. (Dual processors etc...)
-- Ian | |
|
#2 | mike 12:13 Sep 24, 2006 |
| Can you try doing a "make clean" and "make"? I can't duplicate this on my FC5 system... | |
|
#3 | wilson.afn 12:55 Sep 25, 2006 |
| Another data point: FC5 (yum last night), FLTK svn 5489, FLWM. NVidia GF4 TI4200 and *propietary* driver V8762.
I use a slightly different procedure to see Ian's effect. Dragging *any* window in front of Mandelbrot renders its interior black (or grey if "-s plastic"). Clicking interior produces another graphic. (This from a guy who has trouble distinguishing a Julia set from a hole in the ground.) | |
|
#4 | matt 03:27 Sep 26, 2006 |
| Sounds like it is related to the overlay window class. That could explain why the ::draw() is never called (maybe calls ::draw_overlay() instead, or similar). Can't replicate on my OS X machine obviously, since uncovering a window does not create a damage on OS X. | |
|
#5 | matt 03:50 Sep 26, 2006 |
| The same bug shows up on Win32. The reason seems to be that the outer window is a double window, but the rendering itself goes directly onto the screen, not into the backbuffer. This explains why "draw()" is not called: the Double_Window simply restoires the backbuffer and does not bother any child widget at all. | |
|
#6 | matt 04:17 Sep 26, 2006 |
| OK, Fl_Window::make_current() does not take double buffering into account. Probably the right thing to do is to copy the offscreen rendering code into "make_current()" and mark the window as exposed, so the backbuffer gets copied to the front.
Any opinions on this? | |
|
#7 | ianmacarthur 10:26 Dec 05, 2006 |
| I just noticed this bug has been assigned to "Example Programs", but actually, if the preceeding analysis is correct, then this is really a "Core Library" bug?
If it is to be treated as an "Example Programs" bug, then the fix is simply to make the Fl_Windows that contain the GL_Windows be Fl_Single_Windows rather than Fl_Double_Windows. Probably... -- Ian | |
|
#8 | matt 07:29 Jan 18, 2007 |
| Fixed in Subversion repository.
Mandelbrot is for now at least drawing the overlay correctly, even on Mac OS X Quartz. I still have to fix the double buffer drawing for make_current. | |
|
#9 | matt 07:40 Jan 18, 2007 |
| I have decided to close this item. The idea of double buffering somewhat conflicts with the use of image buffers here. Changing the WIndow type to single buffering resolves this conflict and make this demo work nicely now.
Yes, there are better solutions, but not without changing the ABI. We would have to replace "Fl_Window::make_current" with multiple functions that allow front or backbuffer rendering, with or woithout flushing to screen... . | |
|
#10 | AlbrechtS 14:17 Feb 06, 2023 |
| FTR: the entire fix consisted of two commits,
svn r5613, git 32a8df787c76d7bd542b5903af86867d8704b8bb and svn r5614, git fbd01308b987713ed7487014f15abb99dd5ae2d2 | |
[ Return to Bugs & Features ]
|
| |