Re: Speeding up stroking of dashed rectangles (was: ideas on improving the performance of gtk_tree_view)

[Nicolas Setton <setton adacore com>]

> What hadn't ever been made clear is if real-world applications were
> seeing performance problems caused by the dashed stroking. It sounds
> like maybe you're on to one of those now.

To be fair, even though it's a "justifiable" use, that's an extreme  
case - with the font I'm using, one tree row is more than one hundred  
thousand pixels long.

> 	if (stroke_style->dash)
> 	    return CAIRO_INT_STATUS_UNSUPPORTED;
>
> After you do that, the results won't be correct, (the focus rectangle
> will come out solid instead of dashed), but it should give you a
> feeling of the upper-bound of the performance benefit you could expect
> from adding dash support to this function, (and also confirm if the
> dashed stroking is the cause of the problems you're seeing).

I commented out the line, and, as expected, the performance becomes  
good. The response time was divided by about 100!

> And if so, then yes, the cairo list might be the best place to
> continue the discussion. In fact, I just decided to pull that list in
> with this reply. Please feel free to drop gtk-devel-list from future
> replies if we just keep talking about cairo's dashed stroking code.

I've kept gtk-devel-list to inform everyone of the results, since  
that's one more argument in favor of integrating Markku's patch.

I'll also take the opportunity to thank again everyone involved in  
these productive discussions. This is one healthy community!

Carl, see you in the cairo list for the continuation of this :) I'll  
try submitting a pertinent test for integration in the perf/ suite,  
and then a tentative implementation of dash support in  
_cairo_path_fixed_stroke_rectilinear.

Nico