Opened 17 years ago
Closed 16 years ago
#1355 closed bug (fixed)
[GLTeapot] last frame stays on screen at close
| Reported by: | diver | Owned by: | phoudoin |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Kits/OpenGL Kit | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | Nate4D@… | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
GLTeapot leaves last frame on screen at close via Alt+q.
Attachments (1)
Change History (12)
follow-ups: 2 4 comment:1 by , 17 years ago
| Component: | - General → Kits/OpenGL Kit |
|---|---|
| Owner: | changed from to |
comment:2 by , 17 years ago
Replying to axeld:
It's not just that, actually it easily draws over other windows as well - and since other BDirectWindow apps obviously don't do that, I'd guess the OpenGL implementation is to blame here.
Although this could also be a problem of BGLView. I thought I'd fixed it some time ago in hrev20844 (see bug #1157), but maybe I was wrong.
comment:4 by , 17 years ago
| Status: | new → assigned |
|---|
Replying to axeld:
It's not just that, actually it easily draws over other windows as well - and since other BDirectWindow apps obviously don't do that, I'd guess the OpenGL implementation is to blame here. You can reproduce the problems much easier with the GLDirectMode test application, btw.
I'm currently in vaccation, with limited internet access. But ASAP I'll investigate the direct mode drawing code, as something is still not quite right.
comment:5 by , 17 years ago
Replying to diver:
Funny thing is that if closed via alt+w everythig ok.
I think it's just not 100% reproducible. For me this bug happens very rarely. It might also be related to the screen depth.
comment:6 by , 17 years ago
Actually I can reproduce it consistently now. Happens only when quitting with ALT-Q.
comment:7 by , 17 years ago
comment:8 by , 16 years ago
| Cc: | added |
|---|
I noticed this problem playing with Haiku on my Ubuntu box in Qemu, and poked at it until I found what I believe is the correct solution.
I'm a total novice at Haiku/BeOS, though, so I'm not sure this is the right fix.
When comparing GLTeapot with some other apps, though, I noticed that the "Quit" menu item posted a B_QUIT_REQUESTED message directly, which does not appear to be the usual approach.
I'm attaching a patch that solves the problem for me, modeled after the way mediaplayer handles quitting via the menu.
I assume that quitting via the close button (Alt+W) is handled by BWindow or similar, and thus, that path didn't suffer from this problem, nor would it in any application as long as BWindow does things right?
Anyway, if someone has the time, please take a look at the patch and see whether it looks like the right approach. There are some stylistic things I'm not too sure about, so please suggest any appropriate alterations.
by , 16 years ago
A possible fix for the bug, with a tiny bit of style cleanup too.
comment:9 by , 16 years ago
The previous method of posting B_QUIT_REQUESTED directly is perfectly allowed. I would look for this problem in the area where the app_server and BDirectWindows communicate the clipping state. There should be a race condition.
comment:10 by , 16 years ago
Okay. Thanks for the info.
I don't have tons of free time, but I may keep looking at this when I do have the time.
comment:11 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Should be fixed in hrev30472, at least I can't reproduce although I could before.
It's not just that, actually it easily draws over other windows as well - and since other BDirectWindow apps obviously don't do that, I'd guess the OpenGL implementation is to blame here. You can reproduce the problems much easier with the GLDirectMode test application, btw.