tabifier plugin still weird in 998

installed the latest tabifier for 998.

1. When I open the plugin dialog, left pane is not visible. When I resize the window, the left pane is visible.

2. The code on the right side does not scroll and it's hard to find the effects of your changes

3. I do not see any OK/Cancel/Apply buttons. So when I make some changes and close the dialog, all my change are lost.

4. Most importantly, when I open the tabifier dialog, the CPU usage goes to 100%. When I close the dialog, the usage goes back to 0-1%.

5 comments
Comment actions Permalink

I meant weird behavior

0
Comment actions Permalink

Why is it just MY plugin that doesn't work? :))

Thanks, Vinay. If I can keep up with the EAP releases and get some time this (vacation) week, I'll try to figure it out.

One thing I think I'll try is to get a thread dump. If the UI code is eating 100% cpu it probably isn't giving the Swing thread much time to paint. So possibly fixing that will fix everything. (Ha.)

-Dave

0
Comment actions Permalink

Same here for 1002

When you find the reason, Dave, could you let us know. I find this problem rather interesting.

Jacques

0
Comment actions Permalink

Will do. I'm sure it will be strange and unique.. :)

0
Comment actions Permalink

Hi all,

I just uploaded tabifier version 4.6 which disables the Preview pane. For some unknown reason (since I don't have IDEA source code :) updating the openapi.editor.Editor's document with new text sent it into a perpetual Swing looping frenzy. Sorry it took me this long to get to it.

The rest of this message contains details that I hope someone from IntelliJ will take a look at and give me a hint as to how to work around the problem.

I took a number of thread dumps while the tabifier settings dialog was consuming 100% of the CPU. The dumps show a common thread backtrace up to a point. Here's one of the dumps.
(a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:817) at javax.swing.JViewport.paint(JViewport.java:722) at javax.swing.JComponent.paintChildren(JComponent.java:647) - locked <0x10a59200> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:817) at javax.swing.JComponent.paintChildren(JComponent.java:647) - locked <0x10a59200> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:817) at javax.swing.JComponent.paintChildren(JComponent.java:647) - locked <0x10a59200> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:817) at javax.swing.JViewport.paint(JViewport.java:722) at javax.swing.JComponent.paintChildren(JComponent.java:647) - locked <0x10a59200> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:817) at javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java:4787) at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4740) at javax.swing.JComponent._paintImmediately(JComponent.java:4685) at javax.swing.JComponent.paintImmediately(JComponent.java:4488) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:410) at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:117) *** THREAD DUMPS DIVERGE ABOVE THIS POINT at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent(EventQueue.java:454) at com.intellij.ide.q.b(q.java:37) at com.intellij.ide.q.a(q.java:131) at com.intellij.ide.q.dispatchEvent(q.java:0) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:141) at java.awt.Dialog$1.run(Dialog.java:540) at java.awt.Dialog.show(Dialog.java:561) at com.intellij.openapi.ui.DialogWrapper$MyDialog.show(DialogWrapper.java:24) at com.intellij.openapi.ui.DialogWrapper.show(DialogWrapper.java:164) at com.intellij.openapi.options.a.f.b(f.java:32) at com.intellij.openapi.options.a.f.access$1000(f.java:44) at com.intellij.openapi.options.a.f$d_.actionPerformed(f$d_.java) at com.intellij.openapi.actionSystem.b.l.a(l.java:25) at com.intellij.openapi.actionSystem.b.l.processMouseEvent(l.java:113) at java.awt.Component.processEvent(Component.java:4897) at java.awt.Container.processEvent(Container.java:1569) at java.awt.Component.dispatchEventImpl(Component.java:3615) at java.awt.Container.dispatchEventImpl(Container.java:1627) at java.awt.Component.dispatchEvent(Component.java:3477) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3198) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3128) at java.awt.Container.dispatchEventImpl(Container.java:1613) at java.awt.Window.dispatchEventImpl(Window.java:1606) at java.awt.Component.dispatchEvent(Component.java:3477) at java.awt.EventQueue.dispatchEvent(EventQueue.java:456) at com.intellij.ide.q.b(q.java:37) at com.intellij.ide.q.a(q.java:105) at com.intellij.ide.q.dispatchEvent(q.java:0) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137) at java.awt.EventDispatchThread.run(EventDispatchThread.java:100) ]]>
I inserted a comment to indicate where the thread backtraces diverge. Other thread dumps show different kinds of Swing work taking place; here's one more as an example.
(a java.awt.Component$AWTTreeLock) at javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.java:353) at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:116) ** DIVERGES ABOVE THIS POINT at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178) ... etc. ]]>
This bug (utilizing 100% CPU) happens only when I perform a Document.replaceString() call, which worked fine up through EAP build 996 (I believe -- possibly the build before or after.) The text is still replaced and appears in the preview pane, but Swing is busy behind the scenes doing work that doesn't change the appearance of the dialog.

MaximS gave me the basic outline of the Preview pane code used in the tabifier. In case it will help you, here it is as I've adapted it:


Maxim, or someone at IntelliJ, could you please check out the stack backtrace and see if I am doing something incorrect, or if there's a bug in your code?

Thanks very much,
-Dave

0

Please sign in to leave a comment.