Just a guess: I suspect that Slick-C does not use "virtual listboxes", and natively fully populates each listbox and treeview with the entire set of data. In a virtual listbox the idea is that the listbox does not manage the list data itself, it merely manages the scrollbar and uses a callback to get the actual data as needed. So the initialization time is almost zero, and the additional memory requirements are almost zero (or put another way, the memory cost is only 1x instead of 2x -- since the host already has the data in memory somewhere).
If SlickEdit used virtual listboxes, there are a few nasty performance issues that would probably be magically solved. There is of course a trade-off, though, because adding virtual listbox support to Slick-C would take time, and also finding and converting the performance-problem listboxes in SlickEdit would also take time. I'm not part of the SlickTeam, so I can't really offer a guess as to how expensive/risky/etc that might be.
But, ignoring the question of cost/risk/side effects/etc (
), and assuming that you are right about the reason for the slowdown, then a virtual listbox implementation would probably make a difference for this particular issue. (Again, lots of qualifiers here, because I don't know any internal details of how SlickEdit is implemented, nor even how X terminals work, though RDP terminals do not seem to suffer from this and therefore I assume that RDP sends rendered information to the client but X terminals replicate the actual windowing state to the client).
