A follow-up to the fix for RT-34443. Quoting the Jim's concern:

Most of the operations that stroke use "stroke.apply(g)" which returns false if the stroke is not applicable. Prior to that we did our intersections with "stroke.getPlatformStroke()" which may not be appropriate if the stroke "is not applicable".

A common way for the stroke to not be applicable is if the stroke.getPlatformStroke() method returns null. For cases where we "fill and stroke" this isn't an issue because we'd still fill the primitive and the null we get back from that method causes us to do the intersection test with a null stroke - i.e. on the fillable bounds. That is OK so far. But, in some cases the only operation being fired off is a stroke operation - this means we will perform the intersection test on a fillable bounds for an operation that will eventually NOP. That will be sub-optimal, but not wrong.

Another way that the stroke could be "not applicable" is if the stroke's paint is null. If the operations is a "stroke only" operation then we may calculate bounds for a strokable version even though it will eventually NOP. If the operation is a "fill and stroke" operation then we will merely overestimate the bounds by a stroke boundary when the stroke part is going to be a NOP.

It's a minor consideration, though, and the fix will still do its job in lots and lots of cases. I'm not even sure how likely either of the above conditions can be (is the stroke always defined in practice and the tests are only for theoretical cases?).