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



On Tue, 27 Mar 2007 17:50:08 +0200, Nicolas Setton wrote:
> Interesting, the dashed stroke is exactly what's causing problems -
> thanks for the pointer!

Ah, ...

> > though I *think* it has been adressed since. But if you are running
> > 1.4, that would hint that it still is a problem.
>
> There have been great advances in cairo performance lately,
> unfortunately this one might have been overlooked. I'll investigate
> further.

It hasn't been overlooked, per se. But we know it hasn't been
addressed yet.

The mention I made of it before, (from GUADEC last year), was with
respect to a synthetic benchmark that just drew a single big, focused
button over and over again as fast as it could. And that example
showed quite clearly that post-cairo GTK+ drew that button much more
slowly than pre-cairo GTK+, (and it is definitely the dashed stroke
that is causing the problem).

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.

> Indeed. Just subscribed to that list. In order to avoid confusing
> everyone, I'll stay on this list for now, and might open future
> topics on performance-list (or on the cairo list, if I can make
> myself useful there).

I'm on all three of the lists, and I'd be glad to continue the
discussion wherever you see fit. Within cairo, for example, there's a
custom _cairo_path_fixed_stroke_rectilinear function that would be the
ideal place to throw in support for really fast dashing.

And I don't think it would even be a huge amount of work to fix that
to support the kinds of dashing used in the focus rectangle here.

One thing you could do that might be very useful would be to go into
that function in cairo and remove the following two lines:

	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).

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.

-Carl

Attachment: pgpqJudTnKLfe.pgp
Description: PGP signature



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