ChangeScreenBuffer() quit problem - is it OK to use windows?

[ChrisH]

As previously mentioned over there, I am having OS lock-ups when my program quits, since I added ChangeScreenBuffer() code (rather than blitting after WaitTOF()). While there could still be a bug hiding in my code, I was wondering if there are any restrictions which the autodocs don't mention.

For example, is it OK to have a (e.g. backdrop) window open on a double-buffered screen? The autodocs seem to imply this is OK, since they say that ChangeScreenBuffer() "Performs double (or multiple) buffering on an Intuition screen in an Intuition-cooperative manner". But they don't clearly state it.

[ChrisH]

I've now narrowed down the crash to when I close the (backdrop) window, so it does seem to be window-related. Would be nice to get a straight answer as to whether windows should work or not. (They DO seem to work, at least until they have to be closed...)

[xenic]

@ChrisH
I'm not qualified to answer your question but I did locate an example on the developer CD (ADCD_2.1/NDK/NDK_3.1/Examples1/intuition/doublebuffer.c) that appears to use ChangeScreenBuffer() and a backdrop window. I ran the binary and it works, plus closes without crashing. If you haven't already checked that example, you might want to compare it to your code to see if it helps.

[ChrisH]

@xenic
Well spotted! So it seems I must be doing something wrong with the window. Will look closer...

[ssolie]

I have updated the wiki with some fresher information on double buffering:
http://wiki.amigaos.net/index.php/Intui ... _Buffering

The example needs to be modernized and probably more explanation added but it's a start.

[ChrisH]

@ssolie
Thanks for that. The wiki makes it much clearer what Intuition stuff supports double-buffering & what doesn't. The main point for me is that backdrop windows DO support double-buffering.

BTW, I believe I have tracked-down the exact circumstances which cause the crash (or avoid it) on exit. I will be posting that on Amigans.net, since Hans/etc is already discussing that kind of stuff. It may or may not be an OS bug.

[Hans]

I've now narrowed down the crash to when I close the (backdrop) window, so it does seem to be window-related. Would be nice to get a straight answer as to whether windows should work or not. (They DO seem to work, at least until they have to be closed...)

They do work and, AFAIK, using a backdrop window is the correct way to get input events. The Composite3Demo uses a backdrop window for this exact reason, and doesn't have any crashing problems. It's source-code is freely available, so you can compare that with what you're doing.**

Hans

** I know that you already know about the Composte3DDemo's source-code, etc., but I'm repeating myself a little for the benefit of those who might read this thread later, and not have the background knowledge to correct the dots.

[ChrisH]

Although I am still awaiting for Hans' response to my latest Amigans.net post, I am now fairly convinced it is an OS bug. Albiet one which will not be seen by typical uses of double-buffering (my usage is a little unusual, albiet perfectly reasonable).

[ChrisH]

I have updated the wiki with some fresher information on double buffering:
http://wiki.amigaos.net/index.php/Intui ... _Buffering

Something that does NOT tell me is whether writing to an intuition window will affect the visible screen bitmap or the hidden bitmap. A problem I am having is making me suspect it will change the visible bitmap (which seems the wrong thing to do IMHO). EDIT: I am now fairly convinced that this is the case. Is there any good reason why Intuition should be writing directly to the screen, rather than the buffer?

EDIT: Or it could even be worse than that. It may be that the window only writes to the original screen bitmap (which sometimes will be the visibile one & sometimes it won't).

[broadblues]

Windows with borders are not supportable on double-buffered screens. Double-buffered screens are expected to consist nearly entirely of custom rendering.

You seem to interpret that as meaning you can render to a backdrop window, but not a bordered one. But I would interpret it as you should not render via the window at all, only use it to capture input.