On Mon, Apr 22, 2013 at 1:35 PM, ed44 <[email protected]> wrote:

> On 04/22/2013 05:29 PM, J. Liles wrote:
>
>> I guess you're talking about drawing to a cairo_xlib surfaces. The xlib
>>> backend
>>> is slow. To get speed use an image surface as a backbuffer and
>>> 'xputimage'
>>> it ( or parts of it ) to a window.
>>>
>> That is (kind of) what NTK does. Do you have any numbers (or a test
>> program) to back up the claim that drawing to an xlib surface (pixmap)
>> and copying it into another is slower than drawing into an image
>> surface and copying that? I'm pretty sure I tested this myself a while
>> ago and determined that there was no difference.
>>
>>
> attached is im-x-test.c
> compile with :    gcc -g `pkg-config cairo --cflags --libs` -lX11
> im-x-test.c -o rtest
>
> no arguments==use image
> one or more args==use xlib
>
> my results :
>
> egag@slack64:$ time ./rtest
> Render to image surface and copy...
>
> real    0m0.136s
> user    0m0.112s
> sys     0m0.011s
> ~/c
> egag@slack64:$ time ./rtest it
> Render to xlib surface and copy...
>
> real    0m1.413s
> user    0m0.102s
> sys     0m0.005s
>
> that's bonus points for the image surface, 10+ times faster;
>
> but of course i picked a non int linewidth....
>


I'm not sure this is valid. Your image surface is not alpha, but the
default X11 visual may be.

I get (free-software radeon driver):


male@sire:~/Downloads$ time ./rtest
Render to image surface and copy...

real    0m0.095s
user    0m0.060s
sys     0m0.016s
male@sire:~/Downloads$ time ./rtest it
Render to xlib surface and copy...

real    0m0.302s
user    0m0.012s
sys     0m0.056s
male@sire:~/Downloads$



>
> Drawing pixel aligned (linewidth 2 or so ) shows a close finish and if you
> scrap the png
> xlib will be faster. But that means no more than hor. and vert. lines and
> fills... not much
> of a graphic lib. that is.


BTW, NTK draws everything pixel aligned and certainly doesn't write pngs.

 Maybe i'll try to make an image surface testcase for the current seq.
> Just to look what it does...
>
>
I really think this is a red herring. If you say it's slow, I believe you,
but I'm pretty sure the drawing alone can't account for that kind of
slowdown.


 I need to know more about
>>>> your environment. Are *all* FLTK1.3 and NTK applications slow for you?
>>>> What video card and driver are you using? What version of X? Have you
>>>> tried switching between EXA and XAA? Have you tried the
>>>> XAAOffscreenPixmaps = "no" Xorg option?
>>>>
>>>>
>>>>  Zynn is OK , non-mixer is always running and when i switch desks
>>> from mixer to sequencer and back i see a blank mixer-window for
>>> 1/4 - 1/3 of a second ( not really a pain ) and a blank seq. window for
>>> about 3/4 - 1  sec.
>>>
>>> I have an NVIDIA card with prop. driver and X.Org X Server 1.9.5.
>>> and never tried or needed other options than standard.
>>>
>> Hmm. Have you tried running it under Xephyr? If it's faster under
>> Xephyr, then it's definitely (at least partly) a problem with your X
>> setup.
>>
>>
> wouldn't other programs also show some probs if that was the case ?
>
>
Not if they use different toolkits which have different ways of interacting
with X and may trigger different bugs.
>
>
>  Ok....take your time...
>
>
Can you please confirm that the 'non-sequencer-reimplement-canvas' branch
is slow or not on your system?

Reply via email to