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

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)

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]