GLTeapot stops rendering when teapot is not spinning.

[bga]

If you start the GLTeapot demo and then click with the mouse inside the teapot so that the teapot stops spinning, the window will also stop refreshing so if any part of the teapot is obscured, that part will disappear until you spin the teapot again. Moving the window itself also make the teapot disappear completely.

Also, it may or may not be related but when the teapot is spinning and you move the window around, there is lots of flickering in the image.

All of this is using the VESA driver and hrev32768.

[axeld]

The flickering is actually caused by two things: Stefano set the background for the BGLView to black instead of transparent. However, the actual reason (and probably why he did that) is that the app_server does not work correctly when moving windows around with double buffering turned on. I'll open a new bug for this, as I don't think it's related to what you're seeing.

[jackburton]

The problem is that the GL addon doesn't redraw to the screen if the teapot is not spinning: since nothing changed from the openGL POV, it doesn't trigger a redraw. To fix this, we could to copy the content of the openGL "front" buffer to the screen on every DirectConnected() (possible, but right now I don't know if there are drawbacks).

[jackburton]

And to add more info: while BGLView has a FrameResized() hook, it doesn't have a FrameMoved(). FrameResized(), in fact, triggers a redraw in the GL addon.

[phoudoin]

Replying to jackburton:

And to add more info: while BGLView has a FrameResized() hook, it doesn't have a FrameMoved(). FrameResized(), in fact, triggers a redraw in the GL addon.

FrameMoved() is not needed because the GL viewport properties won't change when the view is moved. If our app_server trigger a full redraw on view move, it's a bug with app_server from which we expect to "bitblit" as much as possible the view content on move, invalidating only the previous invisible part.

Regarding the black background, we do have an issue regard the transparent/non transparent color and our currently forced single-buffer rendering. I've other few majors bugs too, which I will create a ticket for, regarding multiple GLView support and creation/destruction issue.

OpenGL Kit is not ready for R1 in his current shape.

[anevilyak]

(In #7941) Indeed.