Support Board
Date/Time: Wed, 10 Jun 2026 17:44:08 +0000
Rendering problems in subinstance
View Count: 21
| [2026-06-10 13:06:06] |
| User512353 - Posts: 143 |
|
Hardware: Intel 12700K CPU, using internal GPU, one 4k monitor attached OS: Debian 13.5, GNOME 48, 9 fixed workspaces, wine 11.0 SC2915 I have a chartbook that does some heavy calculations involving multiple spreadsheets, but with a modest chart update interval of 250ms. When I load this chartbook in the Main Instance of SC, it works well with good responsiveness. When I load this chartbook in a sub-instance, performance degrades massively: The 8 charts in the chartbook update normally, but the detached trade windows, the spreadsheets, and the status bar, draw extremely slowly, like 3-4 seconds per widget. The complete rendering takes minutes. And mouse actions on any window/widget are extremely slow. The very slow redraw occurs with every switch to the workspace. And when there is no data stream, i.e. in the one hour after session close, the problem does not show! I checked CPU and GPU performance while the problem shows, i.e. when switching to the workspace. There is no observable CPU or GPU bottleneck. Total CPU utilization is 10-15%, p-cores <70%, e-cores <10%, GPU renderer <7%. I have used this chartbook in earlier SC versions in sub-instances with no such problems - as far as I can remember. However, one thing that is new now: This is not the only SC Main instance that uses sub-instances. It is in fact the second Main instance with DTC protocol server ports set to 11097 ans 11096. Not sure if that plays a role, but maybe it is worth mentioning. Any idea what the problem is? |
| [2026-06-10 15:06:26] |
| John - SC Support - Posts: 46606 |
|
Do you have any other chartbooks open in the sub-instance where this is occurring? Also, you should look for items that might be slowing down that instance for some reason. I happened to be doing some testing in which I need a "Current Bid Volume" column in my DOM. It was there for a few days and one day I was having trouble with that instance running very poorly. I tried a number of items to clear things up, but nothing worked. I eventually loaded a different chartbook and everything was fine. I realized that the accumulation of the data in that column was the culprit. The point being that there can be things that are in your chartbook that can cause trouble over time. Dense data in the DOM, transparencies, etc. Be sure to look for these as well, as you may not have them occurring when you move the chartbook to another instance. For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2026-06-10 17:36:18] |
| User512353 - Posts: 143 |
|
It is the only chartbook in the sub-instance. There is no chart-DOM or trading-DOM open in the chartbook, no t&s window either. As far as I can quickly overview this, there are no transparencies in the chartbook, and definitely no CPU-heavy studies like VbP or TPO. The spreadsheets do heavy calculations, I think about 1000 rows. However, all this does not explain why the problem only shows up in the sub-instance. From my observation that the problem disappears when the data stream ends at 16:00 central time, plus the fact that no CPU or GPU stress is observed, (plus my 30+ years professional programming experience :-)), I would conclude that there is a problem somewhere in the concurrent execution of the DTC client and the graphics renderer, where either something is repeatedly stalled waiting on some semaphore or something like that, or the rendering process for some reason is not granted sufficient time slices. But I am no expert on GDI questions. It does not look like a GDI renderer or compositor problem to me, because the GUI is not frozen, e.g. if I click on a scrollbar at the bottom of a chart window, with many seconds delay it will do the scroll, long before the extensive rendering process on the widgets is complete. The problem is somewhere else. I should have mentioned: The chartbook is charting MNQ, so it is definitely getting massive amounts of data. And again: The charts itself in all chart regions do update correctly without noticeable delay. It is just the other "parts" on the main window and child windows that show the massive rendering delays. |
To post a message in this thread, you need to log in with your Sierra Chart account: