Issue 1121463002: Move bounds to GrBatch

Issue 1121463002: Move bounds to GrBatch (Closed)

Created:
5 years, 7 months ago by joshua.litt

Modified:
5 years, 7 months ago

Reviewers:
joshualitt, bsalomon, robertphillips

CC:
reviews_skia.org

Base URL:
https://skia.googlesource.com/skia.git@master

Target Ref:
refs/heads/master

Project:
skia

Visibility:
Public.

More Reviews

Description

Move bounds to GrBatch BUG=skia: Committed: https://skia.googlesource.com/skia/+/99c7c07e0f1f7b78980eb21d84bebda8b45a7178

Patch Set 6 : tweak #

Created: 5 years, 7 months ago

Download [raw] [tar.bz2]

	Unified diffs	Side-by-side diffs	Delta from patch set	Stats (+136 lines, -95 lines)			Patch
M	gm/beziereffects.cpp	View	1 2	5 chunks	+5 lines, -5 lines	0 comments	Download
M	gm/convexpolyeffect.cpp	View	1 2	3 chunks	+3 lines, -3 lines	0 comments	Download
M	src/gpu/GrAAConvexPathRenderer.cpp	View	1 2 3 4	3 chunks	+6 lines, -7 lines	0 comments	Download
M	src/gpu/GrAADistanceFieldPathRenderer.cpp	View	1 2 3 4	3 chunks	+6 lines, -4 lines	0 comments	Download
M	src/gpu/GrAAHairLinePathRenderer.cpp	View	1 2 3 4	5 chunks	+6 lines, -10 lines	0 comments	Download
M	src/gpu/GrAARectRenderer.cpp	View	1 2 3 4	6 chunks	+10 lines, -9 lines	0 comments	Download
M	src/gpu/GrAtlasTextContext.cpp	View		3 chunks	+4 lines, -1 line	0 comments	Download
M	src/gpu/GrBatch.h	View	1 2 3 4 5	3 chunks	+13 lines, -2 lines	0 comments	Download
M	src/gpu/GrContext.cpp	View	1 2 3 4	7 chunks	+18 lines, -12 lines	0 comments	Download
M	src/gpu/GrDefaultPathRenderer.cpp	View		4 chunks	+9 lines, -7 lines	0 comments	Download
M	src/gpu/GrDrawTarget.h	View		1 chunk	+1 line, -2 lines	0 comments	Download
M	src/gpu/GrDrawTarget.cpp	View	1 2 3 4	2 chunks	+9 lines, -4 lines	0 comments	Download
M	src/gpu/GrInOrderDrawBuffer.cpp	View	1 2 3 4	3 chunks	+5 lines, -4 lines	0 comments	Download
M	src/gpu/GrOvalRenderer.cpp	View	1 2	16 chunks	+23 lines, -8 lines	0 comments	Download
M	src/gpu/GrTargetCommands.h	View	1 2 3 4	2 chunks	+0 lines, -12 lines	0 comments	Download
M	src/gpu/GrTessellatingPathRenderer.cpp	View	1 2 3 4	1 chunk	+3 lines, -0 lines	0 comments	Download
M	src/gpu/GrTestBatch.h	View	1 2	1 chunk	+3 lines, -1 line	0 comments	Download
M	src/gpu/effects/GrDashingEffect.cpp	View	1 2 3 4	4 chunks	+12 lines, -4 lines	0 comments	Download

Messages

Total messages: 15 (3 generated)

Expand Messages | Collapse Messages | Show Generated Messages | Hide Generated Messages

bsalomon

mostly looks good to me. I'm surprised we need the bounds for clipping. https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h File ...

5 years, 7 months ago (2015-04-30 18:53:24 UTC) #3

bsalomon

On 2015/04/30 18:53:24, bsalomon wrote: > mostly looks good to me. I'm surprised we need ...

5 years, 7 months ago (2015-04-30 18:53:55 UTC) #4

robertphillips

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrAARectRenderer.cpp File src/gpu/GrAARectRenderer.cpp (right): https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrAARectRenderer.cpp#newcode699 src/gpu/GrAARectRenderer.cpp:699: fDevOutsideAssist joined with fDevOutside ? https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h File src/gpu/GrBatch.h (right): ...

5 years, 7 months ago (2015-05-01 13:03:00 UTC) #5

joshualitt

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h File src/gpu/GrBatch.h (right): https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h#newcode111 src/gpu/GrBatch.h:111: void setBounds(const SkRect& newBounds) { fBounds = newBounds; } ...

5 years, 7 months ago (2015-05-01 13:22:28 UTC) #6

bsalomon

5 years, 7 months ago (2015-05-01 13:24:53 UTC) #7

joshualitt

feedback inc https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h File src/gpu/GrBatch.h (right): https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h#newcode111 src/gpu/GrBatch.h:111: void setBounds(const SkRect& newBounds) { fBounds = ...

5 years, 7 months ago (2015-05-01 13:49:58 UTC) #8

feedback inc

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h
File src/gpu/GrBatch.h (right):

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h#newco...
src/gpu/GrBatch.h:111: void setBounds(const SkRect& newBounds) { fBounds =
newBounds; }
On 2015/05/01 13:24:53, bsalomon wrote:
> On 2015/05/01 13:22:28, joshualitt wrote:
> > On 2015/05/01 13:03:00, robertphillips wrote:
> > > Why not "const SkRect&" ?
> > 
> > not sure I follow, the function signature is "const SkRect&"??
> 
> Rob writes his comments using 0-based indexing. So this command for line 111
is
> what you and I would think of as line 112. :)

lol, okay so, clients need to outset / map this rect.  I could either expose
every rect method which might be used, or always force the client to stack
allocate a rect, and then copy it into the class.  I'd rather not copy, even if
this breaks encapsulation a bit.  Its only exposed to derived classes, so unless
you *REALLY* want me to do the copy, I'd prefer it stay the way it is.

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h#newco...
src/gpu/GrBatch.h:114: // TODO will our bounds ever actually be empty?
On 2015/04/30 18:53:23, bsalomon wrote:
> probably should never be empty. Why have a batch that we know will affect zero
> pixels?
> 

Well, it looks like the bounds for horizontal / vertical lines show up as empty.

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrDrawTarget.cpp
File src/gpu/GrDrawTarget.cpp (right):

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrDrawTarget.cp...
src/gpu/GrDrawTarget.cpp:178: if (!this->setupClip(pipelineBuilder, &arfp, &ars,
&scissorState, &bounds)) {
On 2015/04/30 18:53:23, bsalomon wrote:
> did you try doing the outsetting after clipping? Wonder if that would be ok.

Acknowledged.

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrDrawTarget.cp...
src/gpu/GrDrawTarget.cpp:182: GrDrawTarget::PipelineInfo
pipelineInfo(pipelineBuilder, &scissorState, batch, &bounds, this);
On 2015/04/30 18:53:24, bsalomon wrote:
> should the bounds be a required param now (non-ptr)?

I can't do this until path is in batch

bsalomon

5 years, 7 months ago (2015-05-01 14:29:55 UTC) #9

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h
File src/gpu/GrBatch.h (right):

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h#newco...
src/gpu/GrBatch.h:111: void setBounds(const SkRect& newBounds) { fBounds =
newBounds; }
On 2015/05/01 13:49:58, joshualitt wrote:
> On 2015/05/01 13:24:53, bsalomon wrote:
> > On 2015/05/01 13:22:28, joshualitt wrote:
> > > On 2015/05/01 13:03:00, robertphillips wrote:
> > > > Why not "const SkRect&" ?
> > > 
> > > not sure I follow, the function signature is "const SkRect&"??
> > 
> > Rob writes his comments using 0-based indexing. So this command for line 111
> is
> > what you and I would think of as line 112. :)
> 
> lol, okay so, clients need to outset / map this rect.  I could either expose
> every rect method which might be used, or always force the client to stack
> allocate a rect, and then copy it into the class.  I'd rather not copy, even
if
> this breaks encapsulation a bit.  Its only exposed to derived classes, so
unless
> you *REALLY* want me to do the copy, I'd prefer it stay the way it is.

Does making fBounds protected solve your problem? It seems a bit silly to have a
private data member with a protected non-const ptr getter unless the base class
can relocate the member. We use protected data members often.

https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h#newco...
src/gpu/GrBatch.h:114: // TODO will our bounds ever actually be empty?
On 2015/05/01 13:49:57, joshualitt wrote:
> On 2015/04/30 18:53:23, bsalomon wrote:
> > probably should never be empty. Why have a batch that we know will affect
zero
> > pixels?
> > 
> 
> Well, it looks like the bounds for horizontal / vertical lines show up as
empty.

Oh, duh. I guess we have a different meaning of "empty" here. Here left==right
is allowed, but left>right is not. We need to make sure join works correctly for
our use case when either rect is a line or point.

joshualitt

On 2015/05/01 14:29:55, bsalomon wrote: > https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h > File src/gpu/GrBatch.h (right): > > https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h#newcode111 > ...

5 years, 7 months ago (2015-05-01 17:00:09 UTC) #10

On 2015/05/01 14:29:55, bsalomon wrote:
> https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h
> File src/gpu/GrBatch.h (right):
> 
>
https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h#newco...
> src/gpu/GrBatch.h:111: void setBounds(const SkRect& newBounds) { fBounds =
> newBounds; }
> On 2015/05/01 13:49:58, joshualitt wrote:
> > On 2015/05/01 13:24:53, bsalomon wrote:
> > > On 2015/05/01 13:22:28, joshualitt wrote:
> > > > On 2015/05/01 13:03:00, robertphillips wrote:
> > > > > Why not "const SkRect&" ?
> > > > 
> > > > not sure I follow, the function signature is "const SkRect&"??
> > > 
> > > Rob writes his comments using 0-based indexing. So this command for line
111
> > is
> > > what you and I would think of as line 112. :)
> > 
> > lol, okay so, clients need to outset / map this rect.  I could either expose
> > every rect method which might be used, or always force the client to stack
> > allocate a rect, and then copy it into the class.  I'd rather not copy, even
> if
> > this breaks encapsulation a bit.  Its only exposed to derived classes, so
> unless
> > you *REALLY* want me to do the copy, I'd prefer it stay the way it is.
> 
> Does making fBounds protected solve your problem? It seems a bit silly to have
a
> private data member with a protected non-const ptr getter unless the base
class
> can relocate the member. We use protected data members often.
> 
>
https://codereview.chromium.org/1121463002/diff/20001/src/gpu/GrBatch.h#newco...
> src/gpu/GrBatch.h:114: // TODO will our bounds ever actually be empty?
> On 2015/05/01 13:49:57, joshualitt wrote:
> > On 2015/04/30 18:53:23, bsalomon wrote:
> > > probably should never be empty. Why have a batch that we know will affect
> zero
> > > pixels?
> > > 
> > 
> > Well, it looks like the bounds for horizontal / vertical lines show up as
> empty.
> 
> Oh, duh. I guess we have a different meaning of "empty" here. Here left==right
> is allowed, but left>right is not. We need to make sure join works correctly
for
> our use case when either rect is a line or point.

feedback inc

bsalomon

lgtm https://codereview.chromium.org/1121463002/diff/80001/src/gpu/GrBatch.h File src/gpu/GrBatch.h (right): https://codereview.chromium.org/1121463002/diff/80001/src/gpu/GrBatch.h#newcode115 src/gpu/GrBatch.h:115: SkRect fBounds; \n?

5 years, 7 months ago (2015-05-01 20:09:06 UTC) #11

commit-bot: I haz the power

CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1121463002/100001

5 years, 7 months ago (2015-05-01 20:39:32 UTC) #14

commit-bot: I haz the power

5 years, 7 months ago (2015-05-01 20:43:38 UTC) #15

Message was sent while issue was closed.

Committed patchset #6 (id:100001) as
https://skia.googlesource.com/skia/+/99c7c07e0f1f7b78980eb21d84bebda8b45a7178

Expand Messages | Collapse Messages | Show Generated Messages | Hide Generated Messages