rocklee has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks!

I have been playing around with Tk and more specifically Tk::Zinc lately (718496); the way I understand it Tk::Zinc uses OpenGL (with -render=>1 of course), so the systems GPU should be doing the heavy lifting, right?

But doing a mouse drag on a Tk::Zinc (or, indeed, a regular canvas) uses a lot of CPU on my system, even with trivial <Motion> callbacks. Is this a known problem? Could it be an issue with my system?

I have a simple item that can be dragged with mouse on a fullscreen canvas/zinc. I grab it and drag it back and forth like a maniac.

Difference in CPU usage is not immediately visible on different resolutions, i.e. 1280x1024 is no better than 1920x1200.

Also, dragging a windowed Perl/Tk app with a packed zinc widget around uses much more CPU than dragging any other kind of window (double that of Perl/Tk without zinc). For comparison dragging a running 720p running mplayer window in the same fashion uses much less (~10%) cpu than dragging a simple rectangle within a pTk app (~20%), and certainly less than dragging a rectangle within Tk::Zinc (~50%).

My laptop is dual core 2ghz (intel), I think it should be sufficient to drag a rectangle..;-) I run latest ubuntu with default perl packages, everything else built from CPAN. Is it possible that compiling perl from source may help on this issue? Or is there simply nothing to do? :-\

This is a problem for me because I plan on doing important things in the background. I don't want to risk losing a lot of cycles to mouse movement.

Linux pvp 2.6.24-21-rt #1 SMP PREEMPT RT Mon Aug 25 19:24:40 UTC 2008 i686 GNU/Linux

This is perl, v5.8.8 built for i486-linux-gnu-thread-multi

Thanks in advance.

Replies are listed 'Best First'.
Re: Tk/Zinc mouse drag performance issues?
by zentara (Cardinal) on Oct 25, 2008 at 13:39 UTC
    Here is a basic drag on a plain Tk::Canvas. It will print out it's pid at start, then you can open an xterm and follow it with "top -p $pid". With the location printouts commented out, I get about 2% cpu while dragging in big circles. With the printouts uncommented, I get 3%. As far as your case, with POE and Tk::Zinc, there are alot of eventloop things going on in the background. I include a simple Zinc drag program, and it uses more, around 15%, probably because of Zinc's greater complexity. Also, I would probably first suggest to remove POE, and just let Zinc run things. Also that fix for centering the model( discussed previously ) is doing a complex calculation during drags. Try without the transform and see if it reduces cpu.

    Finally remember the limits of your poor little computer. Hollywood animation companies have a big air-conditioned room full of super-computers all running assembly, to do their animations. As you start asking for more and more calculations during a drag, your cpu will go up.


    I'm not really a human, but I play one on earth Remember How Lucky You Are

      You are.. quick!;-)

      Thanks for your input, yet again. I get roughly the same CPU usage on your sample scripts; Admittably my pTk test script had a somewhat complex callback.

      I guess I'll just be very careful about what I do in motion callbacks. (zinc-demo scripts show this to some extent on my system; clipping=25%, MagicLens=90%, testGraphics=40-50%, curve_bezier=25% etc). Notable exception is window-contours, I have yet to figure out why.

      Also that fix for centering the model( discussed previously ) is doing a complex calculation during drags. Try without the transform and see if it reduces cpu.

      Actually I was referring to simple test scripts with just the translate() and no transform() (except the POE+Zinc 90% which was the application you know). The transform() by the way is very simple extrapolation, considering it's written in C it should be lightning fast. I'll test it though, trivial to write in assembler if it turns out to be a problem area (having never tested Inline::ASM, - how does that perform?)..

      I have concluded to remove POE for the next rewrite, as it adds overhead and confusion. I plan on learning about bless() and isolating my code properly in modules instead of poe states, but I have some reading and experiments to do ;-)

      Even though the hollywood studios have rack power, a modern GPU should chew these effects easily.. But I guess i'll write it off on the account of perl flexibility;(

      btw, I compiled 5.10 from source, no noticable difference.

        You might be pleasantly surprised by the performance of this. The secret is to reuse objects.

        I'm not really a human, but I play one on earth Remember How Lucky You Are