gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Simple tasks for OpenGL and Cairo to allow automated tes


From: strk
Subject: Re: [Gnash-dev] Simple tasks for OpenGL and Cairo to allow automated testing
Date: Wed, 6 Jun 2007 13:07:40 +0200

On Wed, Jun 06, 2007 at 06:35:51AM -0400, Quinn Storm wrote:
> On Wednesday 06 June 2007 05:33:18 strk wrote:
> > On Wed, Jun 06, 2007 at 05:25:34AM -0400, Quinn Storm wrote:
> > > On Wednesday 06 June 2007 05:17:30 strk wrote:

> > > This would be *possible* (with libosmesa), but the obvious problem is we
> > > could end up using openGL features that don't render properly on
> > > everyone's driver anyway (despite openGL being a standard, etc.,
> > > implementations are buggy, c.f. standards like ACPI, etc.)  I'm not
> > > against it in principle, just want to point out the bugs that can happen
> > > with it.
> >
> > Do you mean we'd need to use *different* functions from the ones we already
> > use for the sole purpose of implementing offscreen buffer rendering ?
> >
> > --strk;
> 
> Probably (I hope) just a different 'glue' code, but what I was referring to 
> is 
> if we only ever test things against offscreen rendering, we are liable easily 
> to run into bugs with various implementations of GL in the 'real world' case 
> (on hardware as opposed to offscreen software rendering)

There's nothing we can do about that discrepancy, I'm afraid.
But testing the *same* calls against on offscreen buffer seems a useful
thing to me. At least shows that it's not Gnash faults if things go bad
in the "real world".

Implementing a *different* glue would be a problem though, as then the two
*glues* would need to be set in sync.
If the glue is just an initialization thing I see no problem.

--strk;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]