Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify Storage Mechanism for Processes #1

Open
rjaltman opened this issue Dec 21, 2016 · 0 comments
Open

Modify Storage Mechanism for Processes #1

rjaltman opened this issue Dec 21, 2016 · 0 comments

Comments

@rjaltman
Copy link
Member

The Bridge currently redraws the entire process list every time there is some sort of change to the number of processes. As you can imagine, this is a costly process (sorry), mostly because the only storage being done now is maintaining an integer counter.

A better way to do this, and one that will help later on when Snowshoes actually gets going with visual overhauls is creating a hash table that hashes all the handles with windows. I haven't worked a ton with said Hash Tables in C#, but have done work with them in C++ and can't imagine they will be too much trouble. That said, this is not something to particularly fool around with in The Bridge.

Now, visually, we have to be able to reference that object in the FlowLayoutPanel. So, we'll still need some sort of reference back to the object proper...but these objects are dynamically generated. What we can likely do is create an object that supports drawing (extends PictureBox?) but stores the handle with it, so we can query each item (I know, linear time, but this shouldn't be happening too often) and run checks with a simple overloaded != operator.

Am I complicating this, or is this an okay method to employ? I'm mostly opening this issue as a reminder that this needs to happen desperately, but this can generate quite a bit of discussion as well. Let's think about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant