|
|
Created:
5 years, 10 months ago by hal.canary Modified:
5 years, 10 months ago Reviewers:
mtklein CC:
reviews_skia.org Base URL:
https://skia.googlesource.com/skia.git@master Target Ref:
refs/heads/master Project:
skia Visibility:
Public. |
DescriptionDM::PDFSink::draw excercises multi-page pdf
BUG=skia:3365
Committed: https://skia.googlesource.com/skia/+/fd4a993f8b162f6ca541514234a81759b67dc64d
Patch Set 1 : . #
Total comments: 2
Patch Set 2 : conversion from int to SkScalar #Patch Set 3 : formatting,consts #Messages
Total messages: 23 (8 generated)
The CQ bit was checked by halcanary@google.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/881343002/1
Note for Reviewers: The CQ is waiting for an approval. If you believe that the CL is not ready yet, or if you would like to L-G-T-M with comments then please uncheck the CQ checkbox. Waiting for LGTM from valid reviewer(s) till 2015-01-28 22:01 UTC
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: Test-Ubuntu13.10-GCE-NoGPU-x86_64-Debug-Trybot on client.skia (http://build.chromium.org/p/client.skia/builders/Test-Ubuntu13.10-GCE-NoGPU-x...) Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-Shared-Trybot on client.skia (http://build.chromium.org/p/client.skia/builders/Test-Ubuntu13.10-GCE-NoGPU-x...)
Patchset #1 (id:1) has been deleted
The CQ bit was checked by halcanary@google.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/881343002/20001
Note for Reviewers: The CQ is waiting for an approval. If you believe that the CL is not ready yet, or if you would like to L-G-T-M with comments then please uncheck the CQ checkbox. Waiting for LGTM from valid reviewer(s) till 2015-01-28 22:04 UTC
The CQ bit was unchecked by halcanary@google.com
halcanary@google.com changed reviewers: + mtklein@google.com
PTAL
Are you seeing anything span multiple pages? https://codereview.chromium.org/881343002/diff/20001/dm/DMSrcSink.cpp File dm/DMSrcSink.cpp (right): https://codereview.chromium.org/881343002/diff/20001/dm/DMSrcSink.cpp#newcode104 dm/DMSrcSink.cpp:104: static const SkRect kSKPViewport = {0,0, 1000,1000}; I suspect a change like this will require us to rethink always clipping SKPs on the Src side. Seems to me that PDF canvases want unclipped SKPs, and everyone else wants clipped SKPs (but not clipped GMs). Interesting problem to think through and see if we can sort out without some sort of hack of Srcs and Sinks identifying themselves to each other.
On 2015/01/28 16:08:30, mtklein wrote: > Are you seeing anything span multiple pages? Many GMs are wider than 612 pixels. > https://codereview.chromium.org/881343002/diff/20001/dm/DMSrcSink.cpp > File dm/DMSrcSink.cpp (right): > > https://codereview.chromium.org/881343002/diff/20001/dm/DMSrcSink.cpp#newcode104 > dm/DMSrcSink.cpp:104: static const SkRect kSKPViewport = {0,0, 1000,1000}; > I suspect a change like this will require us to rethink always clipping SKPs on > the Src side. Seems to me that PDF canvases want unclipped SKPs, and everyone > else wants clipped SKPs (but not clipped GMs). Interesting problem to think > through and see if we can sort out without some sort of hack of Srcs and Sinks > identifying themselves to each other. We want to clip for bitmap output, but not for stream output. Let me take a look.
> We want to clip for bitmap output, but not for stream output. Let me take a > look. That's a bit that discriminates this choice correctly today, but it's not clear to me that's really the fundamental distinction here. Might be though. Srcs don't think about bitmaps and streams today, and I'd like to keep it that way if possible.
https://codereview.chromium.org/881343002/diff/20001/dm/DMSrcSink.cpp File dm/DMSrcSink.cpp (right): https://codereview.chromium.org/881343002/diff/20001/dm/DMSrcSink.cpp#newcode184 dm/DMSrcSink.cpp:184: const SkScalar kLetterWidthScalar = SkIntToScalar(kLetterWidth); I think this would be more readable with fewer constants and more consistent naming. Let's fold these kLetter*Scalar into letterRect (and just call it 'letter'?), and translate like this: canvas->translate(-letter.width()*x, -letter.height()*y); I also find it's more readable to initialize related values of the same type in one multi-line statement, aligning both on the = and where semantically appropriate in the names: int width = src.size().width(), height = src.size().height(); const int kLetterWidth = 612, // 8.5in * 72 dpi kLetterHeight = 792; // 11in * 72 dpi It's confusing to see some things be 'const T kFoo' and others be 'T foo' when neither changes. E.g., why is it not const SkRect kLetterRect? Or const int kWidth? This code is very local, so there's no real need to go nuts with kPrefixes... 'const int width', 'const int letterWidth' is plenty reminder. With code as small as this is, you might find it even more readable to drop const altogether. The noise of long names, repeated types in declarations, const and kThis are coming together to overpower the meat of the code here.
Patchset #4 (id:80001) has been deleted
The CQ bit was checked by halcanary@google.com
some changes. let's land and iterate.
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/881343002/60001
Note for Reviewers: The CQ is waiting for an approval. If you believe that the CL is not ready yet, or if you would like to L-G-T-M with comments then please uncheck the CQ checkbox. Waiting for LGTM from valid reviewer(s) till 2015-01-29 01:38 UTC
lgtm
Message was sent while issue was closed.
Committed patchset #3 (id:60001) as https://skia.googlesource.com/skia/+/fd4a993f8b162f6ca541514234a81759b67dc64d |