Dragging mouse is extremely slow

kalle · Post by **kalle** » Wed Jan 07, 2009 5:12 pm

The thing here is that the xor rendering is SLOW. It breaks the acceleration in windows machines (in my experience at least). I've got my own zooming rendering, semi-transparent rectangle without any XORring. It's working perfectly without a hitch with the acceleration.

Dropping acceleration is not an option when doing a desktop app. Especially when it's easy to have more than that basic-XOR.

Try to render your own zoom rect, see how it works. I'm not going back to the official zooming.

Post by **david.gilbert** » Wed Jan 07, 2009 8:56 pm

How do you do the zoom rect without redrawing the chart? No problem if the ChartPanel is using the off-screen image buffer, but what if it isn't? It would be nice to fix this one for the next release.

kalle · Post by **kalle** » Wed Jan 07, 2009 9:26 pm

True, I used buffered charts, never saw much sense in the non-buffered.

Post by **david.gilbert** » Wed Jan 07, 2009 10:09 pm

kalle wrote:True, I used buffered charts, never saw much sense in the non-buffered.

It's just a trade-off between memory and CPU. For simple charts, re-rendering is quick, so keeping a BufferedImage is wasteful, but for more complex charts rendering takes longer so buffering really helps for repaints where the chart is unchanged. If you have plenty of RAM, then buffering all the time is simplest.

kalle · Post by **kalle** » Thu Jan 08, 2009 6:24 am

I've done some animal testing with different buffering strategies and best results were (performance wise) by buffering entire screen full, and sharing that across charts. This allowed chart resizes to be as small as possible.

I've since given up on that based on the memory consumption. But it was blazing.

Post by **david.gilbert** » Thu Jan 08, 2009 8:59 am

I don't see how sharing one full screen buffer between all charts would help (if it did, then we'd just use Swing's built-in double-buffering).

One of the situations where the buffering helps a lot is when you have a chart in one frame overlapped by anything (but perhaps another chart) in another frame. After you move the top frame to reveal the partially obscured chart frame below, the lower chart either has to be re-rendered (slow) or simply copied from the buffer (fast, but uses more memory). But if you've got just one full screen buffer with overlapping charts, then the partially obscured chart will have to be re-rendered. That's why each and every ChartPanel has its own BufferedImage for buffering (if that option has been selected).

kalle · Post by **kalle** » Thu Jan 08, 2009 11:36 am

Yeah I totally agree with you. I did not go all the way with my analysis, but in our case (might be other issues as you said) it was improving the situation. Back then I concluded that this was due to creating new buffered images (happened a lot for a lot of charts). But it was really tricky to have it working properly, and not worth the boost (that might not be real, so I'm not suggesting people to go that way).

tomkieffer · Post by **tomkieffer** » Fri Jan 09, 2009 5:52 pm

For completeness, the property

System.setProperty("sun.java2d.d3d", "false")

is not a runtime JVM setting, but if you set this as first line in the static void main method, it works.

bensond · Post by **bensond** » Fri Jan 09, 2009 5:53 pm

But that doesn't help a library, does it...

Post by **david.gilbert** » Thu Jan 15, 2009 6:28 pm

david.gilbert wrote:How do you do the zoom rect without redrawing the chart? No problem if the ChartPanel is using the off-screen image buffer, but what if it isn't? It would be nice to fix this one for the next release.

I'm testing a patch that uses XOR for the zoom rect *only* when the off-screen image buffer isn't being used. So far it seems to work quite well, so hopefully I can get this into the next release.

uli · Post by **uli** » Thu Apr 16, 2009 7:13 pm

Hi,

I have a similar mouse/zoom problem as described in this thread. But in my case the mouse zoom rectangle is not slow but draws incorrectly. Instead of a rectangle several horizontal and vertical lines are produced. The faster the mouse is moved the more lines are there. In the thread the 'ScatterPlotDemo1' is mentioned. When I try this I also get very many lines. (I can even fill the complete plot with blue color when I move the mouse slowly enough from top to bottom).

From the discussion in this thread it seems to be a problem with XOR rendering on Windows XP, but I didn't get the point on how to get rid of it. By the way the same stuff happens on Windows Server 2003 (Standard Edition, SP2) and it's the same for JFreeChart 1.0.9 as well as 1.0.12, no matter if I use JRE 6 or JRE1.5.0_12. This problem resists since about two years now!

I'm very grateful for any advice!!

Post by **david.gilbert** » Thu Apr 16, 2009 8:41 pm

In the next release (1.0.13) there are some changes to the defaults in the ChartPanel class so that XOR drawing will be avoided, in order to work around the problem. 1.0.13 will be out very soon I hope...

bensond · Post by **bensond** » Thu Apr 16, 2009 9:31 pm

The latest JDK beta has the XOR painting bug fixed also, fyi.

Post by **david.gilbert** » Thu Apr 16, 2009 9:50 pm

Oh, that's good. Last time I looked I got the impression it wasn't going to be fixed any time soon. Anyway, I'll retain the changes I made to JFreeChart anyway, and steer clear of XOR mode by default.

uli · Post by **uli** » Sun Apr 19, 2009 1:39 pm

... sounds good, perfect!

www.jfree.org

Dragging mouse is extremely slow

Re: Dragging mouse is extremely slow

Re: Dragging mouse is extremely slow

Re: Dragging mouse is extremely slow

Re: Dragging mouse is extremely slow

Re: Dragging mouse is extremely slow