RENDERING: Tile rendering failure

Bug #514649 reported by Troy James Sobotka
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
New
Undecided
Unassigned

Bug Description

Summary: Rendering at higher resolutions results in tiled rendering failure. Symptoms include patches of incomplete rendering.

Version: bzr 9012

Platform: Linux amd64 (Ubuntu 9.10)

CPU Cores: 4

Additional Information: Rendering should be as "correct.jpg". Correct is rendered at 1000 pixels. The incorrect render happens at 2000 pixels. Source SVG provided.

Tags: renderer
Revision history for this message
Troy James Sobotka (troy-sobotka) wrote :
Revision history for this message
Troy James Sobotka (troy-sobotka) wrote :
Revision history for this message
Troy James Sobotka (troy-sobotka) wrote :
Revision history for this message
su_v (suv-lp) wrote :

> Rendering at higher resolutions results in tiled rendering failure
Do you mean rendering when exporting to PNG via 'File > Export Bitmap...'? What is 'tiled rendering'?

Sorry if I misunderstood, but what is the difference to bug #180495 “RENDERING: Errors with missing vertices and fill areas”?

tags: added: renderer
Revision history for this message
Troy James Sobotka (troy-sobotka) wrote :

Greets ~suv. The difference is rather large.

In the other scenario - the _actual_ display is corrupted by vertices and path corruption. This is somehow bound to the display zoom level as if you tweak the zoom value, the image will display correctly without completely broken paths. So, in summary, the other bug relates to actually corrupted paths.

If you look closely at the incorrect output on this bug and realize that Inkscape is actually rendering the blurs properly within the view, you can quickly see that this is somehow tied to the newer blur tiled multi-core code. It seems the cores are not finishing for the selected tiled regions for some reason. Further still, simply by changing the _output_ DPI (and as a result not making it too complicated for the tiler?) the render is correct.

So while one is bound to vertex issues and mangling, the other is bound to blur core rendering.

I hope this helps.

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

I've notified Jasper van de Gronde, maybe he can tell what's going wrong here.

Revision history for this message
Jaspervdg (jaspervdg) wrote :

It appears to be a problem with how the file is sliced up during export rather than a multithreading issue. Disabling multithreading didn't help (at least on my machine) while the image did come out alright when I specified that the export should be done in just one go (see attachment). This is a very old problem and I'll have a look to see why it reared its ugly head again.

I also think I saw some issues when zooming out though, so I might get back to that later. (This image is very interesting for testing blur as it has very sharp and large discontinuities in very irregular patterns.)

Revision history for this message
Jaspervdg (jaspervdg) wrote :

I've found that it is in fact NOT a problem with filtering (at all). Apparently something goes wrong in drawing the paths, as you can see in the attached file where I disabled the gaussian filter completely.

Revision history for this message
Jaspervdg (jaspervdg) wrote :
Revision history for this message
Jaspervdg (jaspervdg) wrote :

BTW, you might notice that the SVG file without blur shows dark bands in a region that is different from the region which is affected in the blurred image. This is probably due to taking different slices of the image in the blurred case. I've double-checked that disabling the blur in Filter::render (at pretty much the lowest level) DOES give dark bands in the regions that are affected in the blurred image.

Revision history for this message
Troy James Sobotka (troy-sobotka) wrote :

@jaspervdg:

Your conclusions on source of the rendering issue then is the topic of this bug - the dividing of the tile system during render.

The second bug that has manifested for you I've already reported a while ago, but #180495.

Beware about the dark bands as they could be related to an error with a fill set to black?

Revision history for this message
Troy James Sobotka (troy-sobotka) wrote :

Darn, no edit in comments. *sigh*

That should read bug #180495

Revision history for this message
Jaspervdg (jaspervdg) wrote :

Just to be absolutely clear, as far as I have been able to determine there is absolutely nothing wrong (in this case) with the filter code, nor with the tiling/slicing/export code. As far as I can see it is purely a problem with Inkscape rendering the paths in this image in the wrong way. As such this might indeed be the exact same issue as bug #180495 (or at least a similar issue).

The reason the tiling/slicing appears to be a problem is that this does seem to affect Inkscape's rendering of the paths, which it most definitely should not (and is far as I can tell it is not the tiling/slicing's fault).

Revision history for this message
Troy James Sobotka (troy-sobotka) wrote :

@jaspervdg:

You might be the only one qualified to kill this bug regardless. It has been open for a _long_ time regarding the corrupted paths / vertices.

I sincerely hope you can at least help someone track it down.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.