[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Two backtraces ... and a hangup
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2015-04-13 12:18:16
Message-ID: alpine.LNX.2.00.1504131415310.7852 () calcifer ! valdyas ! org
[Download RAW message or body]

On Fri, 10 Apr 2015, Richard Theil wrote:

> 
> Am 10.04.2015 um 13:02 schrieb Boudewijn Rempt:
> 
> > I think that we shouldn't build the Neon packages with asserts enabled.. I can \
> > replace the asserts by returns, then that wouldn't happen.
> 
> Hehe; not exactly my idea of software development ;) They're there for a reason and \
> from what I can see, it would not be a good idea to call setControlPoint1 with \
> Not-A-Number (or Infinity?) values in the first place.

Yeah, that's why I haven't done that yet. The problem is, it's a part of 
the codebase that I am not overly familiar with -- and the original author 
isn't around anymore!

> 
> > From what you say, it sounds like it's really easy for you to reproduce, but I \
> > haven't managed yet! Could you install the debug symbols and try to reproduce?
> 
> I'll have a look into it as i get some play time. However, I just gave 
> it a quick look again, just using the mouse, to see whether issues are 
> maybe dependent on the ancient Wacom hardware. Test case was painting 
> the kanji chars at unicode 5b50, 5f8b, and 76f4. Wacom was disconnected, 
> Mouse was an Apple trackball mouse. Built in T500 TrackPad/Point 
> available, but untouched.
> 
> I ran into a hangup after about a dozen characters drawn. Not a crash, 
> but a seemingly (*) endless looping output of "reached 
> MAX_RECURSIVE_DEPTH" in KarbonSimplifyPath::subdivideAux. That function 
> in turn calls KoPathPoint::setControlPoint1. Coincidence?

I suspect not :-).

> 
> (*) As I read some "calligra-2.9.2" code on the web, It should limit the 
> subdivisions off at MAX_RECURSIVE_DEPTH. So it might not have been 
> technically endless, but just an attept to print around 1024^2/2 lines, 
> which would occur if some input value of the original curve is so NaN 
> that the final comparison in isSufficentlyFlat always returns false.
> 
> Rich
> 
> by the way, in isSufficentlyFlat, you could factor out the division by 
> (SUBDIVISION_COEFF*SUBDIVISION_COEFF) to save a few cycles. Might even 
> help, because that's probably called rather often.

I'll try and look into that, but if you could come up with a patch... 
Well, undying gratitude would be your reward!

> 
> _______________________________________________
> Krita mailing list
> kimageshop@kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]