On 04/24/2013 03:26 AM, J. Liles wrote:
On Mon, Apr 22, 2013 at 1:35 PM, ed44 <[email protected]
<mailto:[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.
Using an ARGB image makes no difference.
Drawing to xlib surfaces is most of the time slower at the moment.
I installed an older cairo-lib to see if there was a change but results
were the same.
One other thing is that the xlib testtime varies over a large range...
I have seen 0.4 sec and also 1.9...
Don't know what to think of that.
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.
Maybe not the drawing alone...
But if you take the following lines out of the "for" loop and
put them right behind that loop, the drawing is the same but
it will be three times faster
-----
cairo_set_source_rgb(cr, 1, 0, 0);
cairo_set_line_width(cr, 3);
cairo_stroke_preserve(cr);
cairo_set_source_rgb(cr, .7, .7, .7);
cairo_fill(cr);
-----
And that tells that drawing takes most of the time.
You can easily verify that.
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.
The non-timeline is not slow. Didn't do much with it yet
but when i load some .wav files i can smoothly drag them around.
Ok....take your time...
Can you please confirm that the 'non-sequencer-reimplement-canvas'
branch is slow or not on your system?
That gives me an Arithmetic exception when i click the main area.
I checked out a fresh repo but the result is the same.
I did reinstall NTK, thought that was necessary, though no change
gdb sais :
Reading symbols from /usr/local/bin/non-sequencer...done.
(gdb) run
Starting program: /usr/local/bin/non-sequencer
[Thread debugging using libthread_db enabled]
The Non-Sequencer 1.2.0 -- Copyright (c) 2007-2013 Jonathan Moore Liles
[non-sequencer] ../sequencer/src/instrument.C:264 get_listing():
couldn't open instrument directory
[non-sequencer] ../sequencer/src/non.H:109 dirty(): song is now dirty
[non-sequencer] ../sequencer/src/canvas.C:236 grid(): viewport: 0:16:32:32
[non-sequencer] ../sequencer/src/canvas.C:356 resize_grid(): resizing
grid 32x32
[non-sequencer] ../sequencer/src/canvas.C:267 _update_row_mapping():
updating row mapping
[non-sequencer] ../sequencer/src/canvas.C:356 resize_grid(): resizing
grid 32x32
[non-sequencer] ../sequencer/src/canvas.C:236 grid(): viewport: 0:0:32:32
[non-sequencer] ../sequencer/src/canvas.C:356 resize_grid(): resizing
grid 32x32
[non-sequencer] ../sequencer/src/canvas.C:267 _update_row_mapping():
updating row mapping
[non-sequencer] ../sequencer/src/canvas.C:356 resize_grid(): resizing
grid 32x1
[non-sequencer] ../sequencer/src/non.H:114 dirty(): song is now clean
create (drawable=3200008)
[non-sequencer] ../sequencer/src/jack.C:562 midi_init(): Initializing
Jack MIDI
[New Thread 0x7ffff37c5700 (LWP 8022)]
[non-sequencer] ../sequencer/src/jack.C:591 midi_init(): allocated
output buffer space for 8192 events
[non-sequencer] ../sequencer/src/jack.C:614 midi_init(): running as
timebase master
[New Thread 0x7ffff2fc4700 (LWP 8024)]
[non-sequencer] ../sequencer/src/jack.C:627 midi_init(): Waiting for JACK...
[non-sequencer] ../sequencer/src/main.C:305 main(): Initializing GUI
X_ChangeProperty: BadValue (integer parameter out of range for
operation) 0x0
create (drawable=320000d)
[non-sequencer] ../sequencer/src/canvas.C:116 draw_background():
redrawing preview
create (drawable=320006e)
finish (drawable=320006e)
Program received signal SIGFPE, Arithmetic exception.
0x000000000040bcd6 in Canvas::grid_pos (this=0x75f950, x=0x7fffffffd6e4,
y=0x7fffffffd6e0) at ../sequencer/src/canvas.C:892
892 *y = (*y - m.margin_top - m.origin_y) / m.div_h;
(gdb) bt
#0 0x000000000040bcd6 in Canvas::grid_pos (this=0x75f950,
x=0x7fffffffd6e4, y=0x7fffffffd6e0) at ../sequencer/src/canvas.C:892
#1 0x000000000040d0f3 in Canvas::handle (this=0x75f950, m=1)
at ../sequencer/src/canvas.C:1452
#2 0x00007ffff6d6fdaf in Fl_Group::handle(int) ()
from /usr/local/lib/libntk.so.1
#3 0x00007ffff6d6fdaf in Fl_Group::handle(int) ()
from /usr/local/lib/libntk.so.1
#4 0x00007ffff6d9ba28 in Fl_Tabs::handle(int) ()
from /usr/local/lib/libntk.so.1
#5 0x00007ffff6d6fdaf in Fl_Group::handle(int) ()
from /usr/local/lib/libntk.so.1
#6 0x00007ffff6d5afa7 in Fl::handle_(int, Fl_Window*) ()
from /usr/local/lib/libntk.so.1
#7 0x00007ffff6db2a92 in fl_handle(_XEvent const&) ()
from /usr/local/lib/libntk.so.1
#8 0x00007ffff6db4b53 in fd_callback(int, void*) ()
from /usr/local/lib/libntk.so.1
#9 0x00007ffff6db4aaa in fl_wait(double) ()
from /usr/local/lib/libntk.so.1
#10 0x00007ffff6d5be48 in Fl::wait(double) ()
from /usr/local/lib/libntk.so.1
#11 0x00007ffff6d5bf9d in Fl::run() () from /usr/local/lib/libntk.so.1
#12 0x000000000042a76d in UI::run (this=0x6d9c10)
at sequencer/src/gui/ui.C:1247
#13 0x0000000000417efc in main (argc=1, argv=0x7fffffffe158)
at ../sequencer/src/main.C:310
(gdb) p *y
$1 = 270
(gdb) p m.div_h
$2 = 0
(gdb)
Looks like a zero devide in canvas.C:892 at the first click.
The 'create' and 'finish' lines are from cairo ( debug )
So i can't say anything about speed yet.
