On 04/24/2013 06:08 PM, J. Liles wrote:
And that tells that drawing takes most of the time.
You can easily verify that.
Takes most of the time *in your test program*--which is not the same
reality as non-sequencer + NTK.
But the same as in the sequencer.
If it was possible to draw the rects in the seq.with one fill an stroke
in stead of hundreds that would speed up the drawing. But that can't be
done.
Using an image surface can be done, and is faster, only i don't know if
that's possible in NTK.
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.
Well, that's good and it leads me to believe that all of the slowness
you see in non-sequencer is stuff I have already fixed in the new branch.
Looks like it...
It also proves that although drawing to an xlib surface might be
slightly slower, it is not actually a problem. Which is a good thing,
because I can't do anything about it until I move all font rendering
from Xft to Cairo in NTK anyway.
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
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.
Try resizing the window (preferably bigger) before you click anything.
I haven't tested it in a non-tiiling WM yet.
That did it.
Looks good, cannot switch to the next pattern but scrolling is ok, zoom
in one direction is smooth so it's drawing fast enough now.
Only the playbar breaks up while playing...
But the speed is ok with this method and that was the goal.
