Re: [Gnash-dev] First stab at fixing an OpenGL bug

[Quinn Storm]

On Sunday 03 June 2007 03:12:35 strk wrote:
> On Sun, Jun 03, 2007 at 03:06:04AM -0400, Quinn Storm wrote:
> > On Sunday 03 June 2007 02:59:38 strk wrote:
> > > On Thu, May 31, 2007 at 06:41:18PM -0400, Quinn Storm wrote:
> > > ..
> > >
> > > > the trouble I'm running into with the bug I was trying to tackle is
> > > > pretty simple.  OpenGL expects an essentially volatile rendering
> > > > pattern, with only transient framebuffers, while gnash expects to
> > > > render to a semi-permanent framebuffer that will stick around until
> > > > changed...and short of doing a back-to-front copy every time anything
> > > > is submitted to render (any line or trimesh), I can't find a way to
> > > > solve this
> > >
> > > A solution would be for OpenGL backend to draw into an offscreen buffer
> > > and copy that to screen. Depending on GUI it could be done in different
> > > ways. For X-based guis, we might use a pixmap. X also has a "backing
> > > store" capability, but is not ensured to work. Anyway using a pixmap
> > > still has the advantage of more control over what's copied.
> >
> > Well unfortunately I have to shoot this idea down right here, as at least
> > on the free driver cards, there is no acceleration at all for the copy
> > that takes place in this situation so it ends up being miserably slow
> > anyhow
>
> What about drawing *both* onscreen and off-screen, so that the copy only
> occurs on expose events ?
>
> --strk;

well, there'd be two drawing contexts so you'd be switching those fairly 
often, which is not a good thing...really, with all the drawbacks, I still 
think the best option is to find a way to accelerate our best backend 
instead, or at best, wait for newer GL drivers for the free cards that 
support the various ops we'd want to make this nice and fast (render to FBO, 
copy to screen, also get nice AA that way through simple supersampling)