Opened 12 years ago

Closed 10 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:
Has a Patch: no Platform: All

Description

GLTeapot leaves last frame on screen at close via Alt+q.

Attachments (1)

1355.diff (3.0 KB ) - added by NateEag 11 years ago.
A possible fix for the bug, with a tiny bit of style cleanup too.

Download all attachments as: .zip

Change History (12)

comment:1 by axeld, 12 years ago

Component: - GeneralKits/OpenGL Kit
Owner: changed from axeld to phoudoin

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.

in reply to:  1 comment:2 by jackburton, 12 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:3 by diver, 12 years ago

Funny thing is that if closed via alt+w everythig ok.

in reply to:  1 comment:4 by phoudoin, 12 years ago

Status: newassigned

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.

in reply to:  3 comment:5 by jackburton, 12 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 jackburton, 12 years ago

Actually I can reproduce it consistently now. Happens only when quitting with ALT-Q.

comment:7 by kaoutsis, 11 years ago

hrev25221, the same here: a) closing with the mouse: ok b) closing with alt+w: ok c) closing with alt+q: last frame stays i was curious to see the behavior of hrev5 GLTeapot for a, b, and c: last frame stays always!

comment:8 by NateEag, 11 years ago

Cc: Nate4D@… 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 NateEag, 11 years ago

Attachment: 1355.diff added

A possible fix for the bug, with a tiny bit of style cleanup too.

comment:9 by stippi, 11 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 NateEag, 11 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 korli, 10 years ago

Resolution: fixed
Status: assignedclosed

Should be fixed in hrev30472, at least I can't reproduce although I could before.

Note: See TracTickets for help on using tickets.