This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Dragging window pane splitter is slow. Perhaps we should disable continouos repainting of panes while the splitter is being dragged, only the splitter outline is painted Dragging editor window across desktop in MDI. This feature may go away if we'll kill overlapping windows in MDI internal desktop.
Peter, please take care of impl of this task. Good solution IMO is to make similar outline like standard swing's JSplitPane has.
Marian's measurement (time in milliseconds): conditions: - SUN UltraSparc60 / 512 MB RAM / Solaris 5.8 / CDE - JDK1.4.1(01) - [nb_dev](200211140100) , MDI - mounted sampledir dragging window pane splitter opened Source Editor (maximalized), drag splitter SE|Explorer 432 503 487 dragging editor window across desktop in MDI 70 71 79 Test cases described on page : http://performance.netbeans.org/qa/TestSuites.html#dragging_window_pane_splitter http://performance.netbeans.org/qa/TestSuites.html#dragging_SE_across_MDI
Note: This seems to be very inefficient solution. It is rather necessary to remove PerimeterPane usage completelly (just makes problems), than waste time trying to make it work like JSplitPane's.
Can you be more specific about problems that PerimeterPane caused us? I personally agree with your conclusion, moreover impl of outline dragging is for free when we will use JSplitPane, but it's better to know why we want to get rid of PerimeterPane. Actually, would it be possible to use results of work in winsys new layout branch for this? This seems to me like attractive solution...
Well, I'm doing on this anyway. To the above, it is just am overall complaint. I think it is alway better use the standard components when possible than create its own ones. It makes it easier maintain and when some typical feature is needed like this one, it could be just switched on. In this case, I can't just switcht it on, I have to implement it from scratch in PerimeterPane, which is a bit difficult, since it doesn't have splits in fact etc., just it wasn't designed that way. This time I could spend if used JSplitPanes before, that's all I wanted to say. To the branch: The views and especially the work with JSplitPanes was done by Marek (cc'ing). I just guess it is not so easy to use, because the branch wasn't finished, and the views were tightly connected to the new model, i.e. split hierarchy. So for the moment, I guess I could solve it this way. Replacing it with JSplitPanes, is still bigger task and not suitable for current time schedule. Although also here some problem could happen. You'll see some results soon.
As far as I remember there is our own splitter in PerimeterPane. I think the only thing to do is to call resize on its panes when dragging is finished not during mouse move. There is already enhancement on this.
Marek, this isn't complete. You have to draw the outline as well. Peter, I'm little bit brain-dead today, so just for clarification - I would be happy if we can get rid of PerimeterPane, exactly for the reasons you mentioned. Just asking - do you plan to throw PerimeterPane out or not now? It wasn't clear to me from you previous comment.
From UI point of view: Suggested solution is ok, but if you want to remove continuous repainting of panes then this splitter outline is really necessary to paint at least.
Created attachment 8694 [details] diff of patch
Created attachment 8695 [details] patch to try out (put it in {nb}/lib/patches directory and restart
Try out the patch. It is almost working. But it has significant drowbacks, it seems it doesn save any time. The technique ised, created background image of the component and then repaints the image and the splitter. The problem is when I tried to paint the clipping region with the splitter only, some component above in AWT hierarchy (my guess) repainted the background thus cleared the components. Also look, at how is painted output window (the part where the scrollbars join -> it shows how bad is output paint done). In sum it seesm it is not so easy to implement the JSplitPane-like feature, and I vote for wontfix of this issue, for this moment, better is later to move to JSplitPanes (which requires bigger work), because this tunig seems to me too risky, to provide some bigger changes in paint mechanism. Please deside.
So I don't see any problem with painted outline on Windows. But I know that on Linux it could have performance problem. So I am ccing Jano Rojcek.
Something's wrong, patch doesn't work for me, it gives me NoSuchMethodError: PerimeterPane.AWTListener<init> It looks like AWTListener inner class is missing in the patch?
Created attachment 8990 [details] Refined diff of patch
Created attachment 8991 [details] Refined diff of patch (previous one is the old one by mistake)
Created attachment 8992 [details] Refined patch
Here is the refined patch, which uses JSplitPane approach by repainting. (The previous one was slightly wrong). Please try it out and let me know whether to put it in. It should be also safer than the previous one. In case of yes, let me know whether to provide switch which would let the old behaviour to work.
I reviewed current patch and I must say: WOW, YES! It's really ok, I've encountered no problems with output window. Try to compare with 3.4 version with some rich window config (many editors opened etc.) and you'll see big difference. I'm amazed and vote for integration.
Yes, it looks good, and works ;-).
Fixed in [trunk]. core/../windows/frames/PerimeterPane.java 1.24
x
fixed
issue doesn't apply to new window system - verified