[Top][All Lists]
[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;