Created attachment 91871 [details] Wrong tile clipping on transformation of target If a target object references a pattern and the target gets transformed, this might influence the size, position and clipping of the pattern surface in a wrong way. Because we have similar problems on filters and maskers it might be an issue with SVGImageBufferTools. But this needs more investigation. Just open the bug for pattern for now. I added an example with a pattern. The target object gets rotated by 225 degree at the center of the circles. Without the rotation the tile of the pattern doesn't get clipped.
Works on Safari, so more likely introduced with SVGImageBufferSupport.
I think this is the root cause of <rdar://problem/9383222>.
(In reply to comment #2) > I think this is the root cause of <rdar://problem/9383222>. What is <rdar://problem/9383222> ?
Created attachment 102678 [details] Another testcase
(In reply to comment #3) > (In reply to comment #2) > > I think this is the root cause of <rdar://problem/9383222>. > > What is <rdar://problem/9383222> ? I've attached the testcase to this bug. The issue goes away when you don't use accelerated compositing, also.
Oh, wait, yours doesn't go away when you turn off accelerated compositing. Maybe they're not related?
Created attachment 102679 [details] Broken with accelerated compositing, fine without
Dirk, can you confirm, it seems like your test case is fixed by http://trac.webkit.org/changeset/94338/trunk Mine will be fixed by my next patch, but I'll make a separate bug since the issues are clearly unrelated now.
(In reply to comment #8) > Dirk, can you confirm, it seems like your test case is fixed by http://trac.webkit.org/changeset/94338/trunk > > Mine will be fixed by my next patch, but I'll make a separate bug since the issues are clearly unrelated now. Just downloaded the nightly r104403 and I don't see the issue anymore. If your test still fails, can you please create a new bug report? Also can someone verify that it just was an issue with WebKit and CG before closing this bug please? Maybe by testing with Chromium Skia or WebKitGtk?
(In reply to comment #9) > (In reply to comment #8) > > Dirk, can you confirm, it seems like your test case is fixed by http://trac.webkit.org/changeset/94338/trunk > > > > Mine will be fixed by my next patch, but I'll make a separate bug since the issues are clearly unrelated now. > > Just downloaded the nightly r104403 and I don't see the issue anymore. If your test still fails, can you please create a new bug report? Also can someone verify that it just was an issue with WebKit and CG before closing this bug please? Maybe by testing with Chromium Skia or WebKitGtk? Chromium Mac nightlies should use Skia, right? The drawing is more aliased than CG, so I'm going to assume it's using Skia. In any case, the problem doesn't reproduce there either. And, I did file another bug for my issue: https://bugs.webkit.org/show_bug.cgi?id=75741 ... I just have to go land it.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > Dirk, can you confirm, it seems like your test case is fixed by http://trac.webkit.org/changeset/94338/trunk > > > > > > Mine will be fixed by my next patch, but I'll make a separate bug since the issues are clearly unrelated now. > > > > Just downloaded the nightly r104403 and I don't see the issue anymore. If your test still fails, can you please create a new bug report? Also can someone verify that it just was an issue with WebKit and CG before closing this bug please? Maybe by testing with Chromium Skia or WebKitGtk? > > Chromium Mac nightlies should use Skia, right? The drawing is more aliased than CG, so I'm going to assume it's using Skia. In any case, the problem doesn't reproduce there either. > > And, I did file another bug for my issue: https://bugs.webkit.org/show_bug.cgi?id=75741 ... I just have to go land it. Ok great. I'll close the bug now.