Summary: | Regression: large SVG from Illustrator comes out blank | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> | ||||||
Component: | SVG | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | rwlbuis, zimmermann | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | 420+ | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Attachments: |
|
Description
Eric Seidel (no email)
2006-12-21 05:31:37 PST
It looks like something is trying to use a mask before it's been attached. item is 0. meaning there is no renderer() on the Masker yet. Here is another copy of the backtrace: #0 0x013de1f8 in WebCore::ImageBuffer::renderSubtreeToImage at ImageBuffer.cpp:40 #1 0x010cb588 in WebCore::SVGMaskElement::drawMaskerContent at SVGMaskElement.cpp:123 #2 0x010cbb98 in WebCore::SVGMaskElement::canvasResource at SVGMaskElement.cpp:143 #3 0x013a1720 in WebCore::getResourceById at SVGResource.cpp:83 #4 0x013a24c2 in WebCore::getMaskerById at SVGResourceMasker.cpp:62 #5 0x0138c42d in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:174 #6 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #7 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #8 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #9 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #10 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #11 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #12 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #13 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #14 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #15 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #16 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #17 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #18 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #19 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #20 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #21 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #22 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #23 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #24 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #25 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #26 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #27 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #28 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #29 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #30 0x011605cb in WebCore::RenderBox::paint at RenderBox.cpp:295 #31 0x0138c5f7 in WebCore::RenderSVGContainer::paint at RenderSVGContainer.cpp:189 #32 0x01153e03 in WebCore::RenderBlock::paintChildren at RenderBlock.cpp:1315 #33 0x0115aec4 in WebCore::RenderBlock::paintObject at RenderBlock.cpp:1369 #34 0x011692ce in WebCore::RenderView::paint at RenderView.cpp:146 #35 0x01182602 in WebCore::RenderLayer::paintLayer at RenderLayer.cpp:1438 #36 0x0118288e in WebCore::RenderLayer::paint at RenderLayer.cpp:1330 #37 0x010e16db in WebCore::Frame::paint at Frame.cpp:1070 #38 0x01102039 in -[WebCoreFrameBridge drawRect:] at WebCoreFrameBridge.mm:481 #39 0x0034158b in -[WebHTMLView drawSingleRect:] at WebHTMLView.m:2678 #40 0x00341961 in -[WebHTMLView drawRect:] at WebHTMLView.m:2729 #41 0x932ee3b1 in -[NSView _drawRect:clip:] #42 0x932ed40b in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] #43 0x0033b2fb in -[WebHTMLView(WebPrivate) _recursiveDisplayAllDirtyWithLockFocus:visRect:] at WebHTMLView.m:893 #44 0x932ec473 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #45 0x0033affb in -[WebHTMLView(WebPrivate) _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] at WebHTMLView.m:848 #46 0x932ed041 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #47 0x932ed041 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #48 0x932ed041 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #49 0x932ed041 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #50 0x932ed041 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #51 0x932ed041 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #52 0x932ed041 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #53 0x932ebb78 in -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] #54 0x932eb362 in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] #55 0x932eac8e in -[NSView displayIfNeeded] #56 0x932eaa32 in -[NSWindow displayIfNeeded] #57 0x0001c394 in ?? #58 0x9333ad6c in _handleWindowNeedsDisplay #59 0x9082a155 in __CFRunLoopDoObservers #60 0x908291f7 in CFRunLoopRunSpecific #61 0x90828eb5 in CFRunLoopRunInMode #62 0x92dcdb90 in RunCurrentEventLoopInMode #63 0x92dcd297 in ReceiveNextEventCommon #64 0x92dcd0ee in BlockUntilNextEventMatchingListInMode #65 0x9326f465 in _DPSNextEvent #66 0x9326f056 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] #67 0x00006f96 in ?? #68 0x93268ddb in -[NSApplication run] #69 0x9325cd2f in NSApplicationMain #70 0x0005f7de in ?? #71 0x0005f6f9 in ?? Hum. Looks like it's been attached, but has not renderer() odd. (gdb) p renderer() $1 = (class WebCore::RenderObject *) 0x0 Current language: auto; currently c++ (gdb) p attached() $2 = true Wow. showTreeForThis() is not very useful with SVGs ;) Perhaps one of its parents responded false to childShouldCreateRenderer(this) (meaning its a mask inside a switch statement). Not sure if that's the case here though. Although that looks like such an SVG would produce a similar bug. Please provide a copy. No longer crashes, but it does come out blank. (In reply to comment #6) > No longer crashes, but it does come out blank. > Does not crash or come out blank in feature-branch anymore. Still has two tiny issues related to bbox calculation/wrong clipping that Rob and me are both aware of and working on. Greetings, Niko (In reply to comment #7) > (In reply to comment #6) > > No longer crashes, but it does come out blank. > > > Does not crash or come out blank in feature-branch anymore. > Still has two tiny issues related to bbox calculation/wrong clipping > that Rob and me are both aware of and working on. Update: the path thing at the bottom that does not show up in webkit, but does in Opera, must be due to filter problems, I think we can skip it for now. The other problem is the ship that is clipped. My guess is that this is to viewBox confusion, but not sure. It is a problem since Opera handles it. Cheers, Rob. Created attachment 15749 [details]
First attempt
This should fix the last problem with treasure_map.svg.
Cheers,
Rob.
Hi Rob,
> This should fix the last problem with treasure_map.svg.
very cool stuff! It like a comment in the code though why viewportTransform
has to be included there, to make it easier to understand.
From what I guess, it's only relevant for <svg> elements which are not the
outermost SVG element, right?
If that assumption holds true, I understood it and give r=me. :-)
Greetings,
Niko
Created attachment 15789 [details]
Also fixing the root <svg>
Nikolas was right, root <svg> needs to also take it into account, so there you go :-)
Cheers,
Rob.
(In reply to comment #11) > Created an attachment (id=15789) [edit] > Also fixing the root <svg> > > Nikolas was right, root <svg> needs to also take it into account, so there you > go :-) > Cheers, Good that it worked out. I'm sorry but I think I see another issue :-) why do you mapRect() the viewportTransform for each child, to unite the mapped rects. From what I see, you could just as well mapRect() the viewportTransform with a single rect afterwards. That will be faster :-) Greetings, Niko I still wish someone would have a brilliant stroke of genius and make all of our container classes make sense some day... ;) I'm glad that the root <svg> object is split out, but I'm saddened that RenderSVGContainer (<g>, etc) needs special <svg> behavior... oh well, that will all go away as part of 1.2 some day. :) (In reply to comment #13) > I still wish someone would have a brilliant stroke of genius and make all of > our container classes make sense some day... ;) I'm glad that the root <svg> > object is split out, but I'm saddened that RenderSVGContainer (<g>, etc) needs > special <svg> behavior... oh well, that will all go away as part of 1.2 some > day. :) Hey Eric, glad to have you back commenting :-) I missed that. This is totally a top-priority issue in feature-branch. I've worked to remove the RenderContainer inheritance, RenderSVGContainer is a true RenderObject nowadays. (The patch you started actually :-) This is in fb since a few weeks. The next step was to split out <svg> specific stuff from RenderSVGContainer in a new class RenderSVGInnerSVGContainer. Then we just have a single RenderSVGContainer class and two special classes inheriting from it, namely: - RenderSVGHiddenContainer (for ie. <defs>) - RenderSVGInnerSVGContainer (for an inner <svg> element within the document) This way RenderSVGContainer will be special-case free clean code, as it should be. RenderSVGRoot represents the outermost <svg> element (it inherits from RenderContainer, to deal with the HTML parent translation offsets). I've worked hard to fix SVG text rendering in XHTML, and in general inline SVG in XHTML problems, ie. for calculating absolute rects, text selection (!). It's way better than it was at WWDC :-) I'm just working on RTL text selection, and after that I plan to do the RenderSVGInnerSVGContainer move. Requesting for comments, of course. In case Rob's patch doesn't break anything (ie. text selection ;-) and if the mapRect() is done after unite(), I'm going to r+ it. Greetings, Niko - RenderSVGRoot OOPS, got the formatting wrong. Retrying with same content: Hey Eric, glad to have you back commenting :-) I missed that. This is totally a top-priority issue in feature-branch. I've worked to remove the RenderContainer inheritance, RenderSVGContainer is a true RenderObject nowadays. (The patch you started actually :-) This is in fb since a few weeks. The next step was to split out <svg> specific stuff from RenderSVGContainer in a new class RenderSVGInnerSVGContainer. Then we just have a single RenderSVGContainer class and two special classes inheriting from it, namely: - RenderSVGHiddenContainer (for ie. <defs>) - RenderSVGInnerSVGContainer (for an inner <svg> element within the document) This way RenderSVGContainer will be special-case free clean code, as it should be. RenderSVGRoot represents the outermost <svg> element (it inherits from RenderContainer, to deal with the HTML parent translation offsets). I've worked hard to fix SVG text rendering in XHTML, and in general inline SVG in XHTML problems, ie. for calculating absolute rects, text selection (!). It's way better than it was at WWDC :-) I'm just working on RTL text selection, and after that I plan to do the RenderSVGInnerSVGContainer move. Requesting for comments, of course. In case Rob's patch doesn't break anything (ie. text selection ;-) and if the mapRect() is done after unite(), I'm going to r+ it. Greetings, Niko Sounds nifty. :) Comment on attachment 15789 [details] Also fixing the root <svg> r=me (and apparently niko) Landed r24932 |