Opened 15 years ago

Last modified 4 years ago

#4355 assigned bug

GLTeapot stops rendering when teapot is not spinning.

Reported by: bga Owned by: nobody
Priority: normal Milestone: R1.1
Component: Kits/OpenGL Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking: #7941
Platform: All

Description

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.

Change History (7)

comment:1 by axeld, 15 years ago

Component: ApplicationsKits/OpenGL Kit

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.

comment:2 by jackburton, 14 years ago

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).

in reply to:  2 ; comment:3 by jackburton, 14 years ago

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.

in reply to:  3 comment:4 by phoudoin, 14 years ago

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.

comment:5 by jackburton, 14 years ago

Owner: changed from jackburton to nobody
Status: newassigned

comment:6 by anevilyak, 13 years ago

Blocking: 7941 added

(In #7941) Indeed.

comment:7 by pulkomandy, 4 years ago

Milestone: R1R1.1
Note: See TracTickets for help on using tickets.