There are a couple of lines in GrContext with FIXME comments (1864, 1929). If I ...
12 years, 3 months ago
(2012-07-17 19:16:24 UTC)
#1
There are a couple of lines in GrContext with FIXME comments (1864, 1929). If I
uncomment them and comment out the paired GrPaint::setTexture() calls,
1. "out/Debug/gm --match circles" succeeds
2. "out/Debug/gm" fails the assert in GrContext.h line 881
1 == temp->getRefCnt()
PTAL? I'm a little unhappy at the verbosity increase, but I think that'll get better ...
12 years, 3 months ago
(2012-07-19 16:01:54 UTC)
#2
PTAL?
I'm a little unhappy at the verbosity increase, but I think that'll get better
over time (as we move Matrix, Filter, Swizzle onto this class, we'll get extra
parameters to the constructor rather than extra lines - although then needing to
get *rid* of this class and move it to a helper to support multi-texture
varying-texture effects will reopen the can of worms).
On 2012/07/19 16:01:54, TomH wrote: > PTAL? > I'm a little unhappy at the verbosity ...
12 years, 3 months ago
(2012-07-19 17:32:11 UTC)
#3
On 2012/07/19 16:01:54, TomH wrote:
> PTAL?
> I'm a little unhappy at the verbosity increase, but I think that'll get better
> over time (as we move Matrix, Filter, Swizzle onto this class, we'll get extra
> parameters to the constructor rather than extra lines - although then needing
to
> get *rid* of this class and move it to a helper to support multi-texture
> varying-texture effects will reopen the can of worms).
LGTM
Is it common enough that we should have a special setter on SamplerState (moved
to DrawState when SamplerState goes away)?
Something like:
void GrSamplerState::setBasicTextureStage(texture, matrix);
On 2012/07/19 17:32:11, bsalomon wrote: > On 2012/07/19 16:01:54, TomH wrote: > > PTAL? > ...
12 years, 3 months ago
(2012-07-19 17:32:54 UTC)
#4
On 2012/07/19 17:32:11, bsalomon wrote:
> On 2012/07/19 16:01:54, TomH wrote:
> > PTAL?
> > I'm a little unhappy at the verbosity increase, but I think that'll get
better
> > over time (as we move Matrix, Filter, Swizzle onto this class, we'll get
extra
> > parameters to the constructor rather than extra lines - although then
needing
> to
> > get *rid* of this class and move it to a helper to support multi-texture
> > varying-texture effects will reopen the can of worms).
>
> LGTM
>
> Is it common enough that we should have a special setter on SamplerState
(moved
> to DrawState when SamplerState goes away)?
>
> Something like:
> void GrSamplerState::setBasicTextureStage(texture, matrix);
Ooh, I like, although I'd name it create? Will file strawman CL once I've landed
this one.
Turns out there was a bug on 3+? codepaths not being caught by gm and ...
12 years, 3 months ago
(2012-07-19 17:59:07 UTC)
#5
Turns out there was a bug on 3+? codepaths not being caught by gm and only
caught by one unit test (WritePixels):
A common idiom previously was
paint->setTexture(...)
paint->sampler->reset(...)
That got turned into
paint->sampler->setCustomStage(...)
paint->sampler->reset(...)
which failed. Reordering the lines fixes the test failures.
Issue 6399053: Add GL implementation to GrSingleTextureEffect, call from GrContext
(Closed)
Created 12 years, 3 months ago by TomH
Modified 12 years, 3 months ago
Reviewers: bsalomon
Base URL: http://skia.googlecode.com/svn/trunk/
Comments: 0