Posted 18 years ago
by Joris Koster
-
Paragon Decision Technology
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]
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]
