Beta3 - Idle SE using one core flat out redrawing

[sndom]

I have an idle SE partially visible behind some foreground windows from other apps.
The main window is split vertically to show two files.

It is using one core flat out mostly in calls to GDI32!BitBlt.

A typical call stack looks like:

GDI32.dll!BitBlt+0xfa
GDI32.dll!BitBlt+0xc7
QtGui4.dll!QRasterWindowSurface::flush+0x292
QtGui4.dll!QRasterWindowSurface::prepareBuffer+0xb0f
QtGui4.dll!QWidgetPrivate::scrollRect+0x17b1
QtGui4.dll!QWidgetPrivate::scrollRect+0x1695
QtGui4.dll!QWidgetPrivate::syncBackingStore+0x70
QtGui4.dll!QWidget::event+0xaaa
vs.exe!slickedit::SEIterator::popStack+0x3625
QtGui4.dll!QApplicationPrivate::notify_helper+0xda
QtGui4.dll!QApplication::notify+0x1ad8
QtCore4.dll!QCoreApplication::notifyInternal+0x72
QtCore4.dll!QCoreApplicationPrivate::sendPostedEvents+0x28a
QtCore4.dll!winGetMessage+0x32d
USER32.dll!TranslateMessageEx+0x2a1
USER32.dll!TranslateMessage+0x1ea
QtCore4.dll!QEventDispatcherWin32::processEvents+0x3ed
QtGui4.dll!qt_getRegisteredWndClass+0x465
QtCore4.dll!QEventLoop::exec+0x215
QtCore4.dll!QCoreApplication::exec+0xe0
vs.exe!slickedit::SEIterator::popStack+0xbb07
vs.exe!vspsGetEnv+0xf35
vs.exe!vspsGetEnv+0x3f957
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21

After switching back to SE and moving the cursor around etc there is no let up on the CPU.
It seems to be redrawing something flat out.

This has been going on for many minutes.

Removing the split to leave one window stopped the CPU thrashing.
Creating a new split did not trigger the same behaviour.

Dom

[Clark]

Next time you hit the problem, try exiting and restarting the editor. This will save your window layout in vrestore.slk. If we are lucky, restarting the editor won't fix the problem and you can post it here. Thanks

[dunkers]

Could this be related to CPU Hogging?

I know that is, on the face of it, about tag file access, but perhaps that's a red herring because that was the only thing I could see SE doing (I wasn't looking at or for GDI calls), and the hogging stopped before the file access stopped.

[Clark]

I believe I had this problem once. The best description for me is "really slow cursor movement" which is what someone else posted.  I was able to exit and restart the editor and still have the problem. Also, it didn't matter whether I had a workspace open or not which leads me to believe that it had nothing to do with tagging.  In fact, I would get the problem in plain text files.

I was in the middle of a number of modifications to the editor source and  I thought I had broken something. To fix the problem, I blew away my config directory. I wish I had saved it!!!!! Taking out my my code changes didn't help. I haven't seen the problem since.

I'm convinced this problem is some weird loop on graphics calls.

[sndom]

I'm convinced this problem is some weird loop on graphics calls.

I'd agree.  I sampled the call stack a number of times and it was down inside BitBlt (as above) on each occasion.

I've had (non-reproducible) issues with the tagging too, and the call stack is quite different.

Dom

[sndom]

Next time you hit the problem, try exiting and restarting the editor. This will save your window layout in vrestore.slk. If we are lucky, restarting the editor won't fix the problem and you can post it here. Thanks

Here you go...  it is hitting BitBlt flat out.

I had noticed that the cursor and general editing response was sluggish.

Dom

[sndom]

Deleting the right most window (with delete-tile, right from the central window) fixed the problem.  Moving the splitter between the two did not.

I had previously resized the application window with the splits in place, but I'm not sure at what point the slowdown started.  It could have been this.

[Clark]

Thanks, ill check it out

[Clark]

To be safe, save your entire config. Also save the files you were editing. I'm hoping I just need your vrestore file. I will make empty files for each of the files you were editing. I will also need to replicate your monitors resolution (its in the vrestore file).

[Clark]

So far no luck reproducing it. Can you try reducing the test case down (less files, no workspace open). This will make this much easier for me to reproduce. I may need the actual files (all characters can be replaced with a single character). The number of lines/columns in the files matters if this problem is due to the scroll bars (which is a likely possibility). First see what you can do to reduce the test case down. Sorry I need more help.

[Clark]

Turn off "auto restore workspace files" before closing the workspace. That way the files and windows won't get closed.

[Clark]

I just had a really good idea on how we can figure out if this is the scroll bars or not. When you get the problem, bring up the options dialog and turn off both scroll bars (Options>Appearance>General> Horizontal/Vertical scroll bar). If turning off the scroll bars fixes the problem, then this problem is due to the scroll bars!

[sndom]

No problem - I'll do this as soon as it happens again.

[sndom]

Ok - I have reproduced this.  When I turn the scrollbars off it stops BitBlt'ing.  When I turn them back on it starts up again.

I have attached the vrestore.slk and copies of the currently visible files (with everything replaced with x's).

Cheers

Dom

[sndom]

Just a quick note to bump this and say that it happened on Beta 4.

Dom