I'm of the opinion (on the basis of inadequate tests by me!) that the crux is
when Fl_Double_Window::flush() tries to create a zero sized Fl_offscreen
surface. If we prevent it from doing so (which is what the OP's workaround did)
then everything seems fine, even if the window is resized to 0,0.
Under 32bits OS,
using the same code, but this generateTree, the tree item over 65536 overlapped
the first one.
May be an unsigned short is used somewhere instead of the original int for
computing Y.
void generateTree(size_t s, vector& tree) {
for ( size_t i = 0; tree.size() < s; ++i )
OK, I've opened STR #2797 for this.
Hopefully one of our X gurus can figure this out.
On 12/19/11 11:10, Greg Ercolano wrote:
> o The issue is definitely triggered when one of the tiles,
> probably 'child window' is resized to zero on either W or H.
> (I nev
On 12/19/11 10:23, Greg Ercolano wrote:
> On 12/19/11 01:40, Albrecht Schlosser wrote:
>> Greg, what happens if you configure FLTK in these cases with
>> --disable-xdbe?
> Yes, I can replicate the errors if I choose --disable-xdbe
> running locally on my centos 5.5/64 box.
>
> Good,
On 12/19/11 01:40, Albrecht Schlosser wrote:
> Greg, what happens if you configure FLTK in these cases with
> --disable-xdbe? Or did you? According to what Ian wrote, this
> would be necessary to replicate the effect, if your system
> used XDBE otherwise (the default).
Hadn't tried it.. I'll g
On 16.12.2011 18:42, Greg Ercolano wrote:
> On 12/16/11 09:12, Ian MacArthur wrote:
>> [32bit vs 64bit observations]
>
> Just to add some info to the mix: I tried a test between
> two linux machines:
>
> 1) fedora 3 32bit/Xorg 6.8.1 (2004)/flwm
> 2) centos
6 matches
Mail list logo
