STR #1438

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 #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)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

No files


Trouble Report Comments:


Name/Time/Date Text top right image
 
#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... .
 
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 'erco@seriss.com'.