[Xr] Clipping problems

[Soorya Kuloor]

Hi Carl,

I found a workaround that does not use clipping for my problem. So I
probably do not need clipping for now. Can you please point me to the
right function to add the rectangular clipping special case code? If it
is simple enough I'll add it and send you a patch.

I am also doing some profiling analysis on the test programs using
valgrind/cachegrind/kcachegrind combination. This combination gives a
really good profiling tool. Unfortunately, I can not find a way to make
kcachegrind dump stats to a file. Does anybody know other good profiling
tools on Linux?

Just to give you some update, for all the things that we tried right now
the performance of Xr seems to be OK. Of-course the graphics quality is
much better compared to traditional anti-aliased graphics that we had
:-).

Thanks,
-- Soorya

On Wed, 2003-06-04 at 07:23, Carl Worth wrote:
> On Jun 2, Soorya Kuloor wrote:
>  > While using clipping stuff I found that it is very slow (you had told me
>  > so before too). Here is a sample application that draws stuff and uses
>  > clipping. Without clipping the painting takes approx. 20-40msecs. With
>  > clipping it takes approx 1500 msecs, that is approx. 50-80 times
>  > slowdown. Are there any plans to fix this pretty soon?
> 
> Soorya,
> 
> I notice that your example happens to use a clipping path that is a
> rectangle aligned with the device pixel grid. That's one case that
> should be quite easy to make ridiculously faster than what currently
> happens.
> 
> Both of the two current backends support setting a clip region,
> (consisting of whole pixels), on the destination surface. It shouldn't
> be too hard to hook up XrClip to use that when possible.
> 
> As always, anyone is welcome to attempt to fix this before I get
> around to it. :)
> 
> -Carl