Redrawing issue when using several or more multiline editors

SyntaxEditor for Windows Forms Forum

Posted 13 years ago by Joris Koster - Paragon Decision Technology
Avatar
Hi,

I've encountered an issue with the redrawing of the syntax editor whenever there are several, in my case 25+ in fullscreen (1280x1024 in my case), editors open.

I have an issue-demo-app that consists of a form, a tab-control, an 'add' button and one filled-docked (multiline) syntax-editor per tabpage. Next I start adding tabs, 5 tabs per button press. In full screen (1280x1024) the syntax editor doesn't paint/redraw anymore after the 25th tabpage.
However, when I resize the form (make it smaller), it is redrawn. Next when I start walking through the tab-pages the problem reoccurs again after 25 switches.

Depending on the size of the syntax editor view this problem will occur more or less frequently. Windows of say 700x600 seem to take about 80-90 editors before the same problem occurs; again after resizing it seems fine, but after walking through the tabpages the same occurs again.

Another feature of this issue, is that it related to the video card; a collegue with a 64 MB shared-mem video card on his laptop seems to be able to handle about half the amount (15+) before the redraw issue occurs, as compared to my Radeon 9800 with 128 MB.

Last but not least, as soon as I succesfully resize (it seems to occur more frequenlty when making the window smaller) such that redrawing occurs, the ammount of used GDI objects drops dramatically.

I suspect this to be a problem with the usage of an underlying windows-layer; in our real application another external component starts having the same problem (while others dont) as soon as we hit the magic amount of editors. Since it is related to the video-card memory size I would suspect some (double) buffering mechanism (provided by Windows-API / .NET) that buffers at the videocard to start failing to do so. As soon as I resize I presume that buffer-structure is invalidated, completely thrown away (since the size changed and linear mem thus not preserved), and rebuild. Invalidation and throwing away happens at all the syntax-editor-controls, rebuilding just at the visible one(s).
It seems like the syntax-editor is holding on to the video-card buffer while not being visible. I would expect that normal memory would be just fine in case it is not visible, thus not polluting the videocard.

Ideally I would like these resources released as soon as the editor isn't visible. An exception on obtaining the resources needed to draw the editor control would also help, since we can then put some code in place to let the user close some windows or do it ourselves.

If you like, I can email the issue-demo-app / source.

PS: it is not the 10,000 GDI / User Objects limitation

[Modified at 08/08/2006 10:42 AM]

Comments (2)

Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
It sounds like the graphics memory is running out with the double buffering. We do maintain a GDI double buffer but clear it on resize (as you found) as well as when the SyntaxEditor.Visible property is changed.

I bet what is happening is that the SyntaxEditor.Visible property isn't being changed when you switch tabs. This would be because the parent control's Visible property is changed, but not the SyntaxEditor one itself. Maybe you could do a test to see if that is the case. If it is, you have a couple options. On a tab change, hide the SyntaxEditor on the old page to fire OnVisibleChanged. Or call the SyntaxEditor.ResetDoubleBufferCanvas method on the old tab's SyntaxEditor, which is what the OnVisibleChanged code calls.

Try that and post if it helps. We don't know of a way to automatically be notified when a control is hidden because of a parent up the Control ancestry being hidden. If you do know of a way, post that too and we can maybe integrate it into our double buffer reset code.


Actipro Software Support

Posted 13 years ago by Joris Koster - Paragon Decision Technology
Avatar
Calling the ResetDoubleBufferCanvas method did do the trick! We now have a stable gdi-user object usage and we can open any number of editors.

If possible I would still like to catch an exception whenever the the editor fails to render (due to not being able to get a resource or whatsoever).
The latest build of this product (v2018.1 build 0341) was released 3 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.