How to keep rendering during user-input
-
Hi, I'll try to explain my problem in as few words as possible so I won't scare anyone off with long posts :) Mission : I'm working on a hobby-project to render graphics that change with user-input. Problem : GfxObjects can be deleted/changed, but *during* rendering that's a big NONO as you'll probably understand :) Possible solutions : - Multithreading. Tried it, it's a very big pain in the arse. GfxObjects could be plugins with their own imported edit-dialogs and I don't want other developers to have the burden of doing locking / unlocking everywhere (and give'em a perfect opportunity to crash my app). - Singlethreaded : OnIdle is fine, it's just not enough. F.e. when the mouse enters the menu, idling stops. Same for window-resizing etc. The ideal way would be : { ProcessUserInput( [for a maximum time of 1/100th sec.] ); RenderFrame(); } I hope some of you guys have suggestions on how to tackle this :) - Lennart Denninger / GameCoder / Guerilla Games
-
Hi, I'll try to explain my problem in as few words as possible so I won't scare anyone off with long posts :) Mission : I'm working on a hobby-project to render graphics that change with user-input. Problem : GfxObjects can be deleted/changed, but *during* rendering that's a big NONO as you'll probably understand :) Possible solutions : - Multithreading. Tried it, it's a very big pain in the arse. GfxObjects could be plugins with their own imported edit-dialogs and I don't want other developers to have the burden of doing locking / unlocking everywhere (and give'em a perfect opportunity to crash my app). - Singlethreaded : OnIdle is fine, it's just not enough. F.e. when the mouse enters the menu, idling stops. Same for window-resizing etc. The ideal way would be : { ProcessUserInput( [for a maximum time of 1/100th sec.] ); RenderFrame(); } I hope some of you guys have suggestions on how to tackle this :) - Lennart Denninger / GameCoder / Guerilla Games
Well like it or not I think you need to use the multithreading approach to get the result you want. One interuptable thread for rendering, and UI back in the main app thread. Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
-
Well like it or not I think you need to use the multithreading approach to get the result you want. One interuptable thread for rendering, and UI back in the main app thread. Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
I know... But it would be nice to have a way to lock the object-system before all the ui-handling and unlock it afterwards. Just like locking it before rendering and unlocking it after rendering. Locking / unlocking for every single change sucks, it means that for someone to write a plugin with an edit-dialog the code would look like this : CEditDlg::OnVar1Changed() { LockObjectSystem(); // change var here mObject->SetVar("General.SplineSegments", 10); UnlockObjectSystem(); } I'd prefer something like { LockObjectSystem(); UpdateALLDialogsAndSettings(); UnlockObjectSystem(); } 'cause in this case the people creating plugins wouldn't need to know about all the locking-stuff, and more important - they wouldn't be able to send my app down in flames by simply forgetting to lock/unlock.
-
I know... But it would be nice to have a way to lock the object-system before all the ui-handling and unlock it afterwards. Just like locking it before rendering and unlocking it after rendering. Locking / unlocking for every single change sucks, it means that for someone to write a plugin with an edit-dialog the code would look like this : CEditDlg::OnVar1Changed() { LockObjectSystem(); // change var here mObject->SetVar("General.SplineSegments", 10); UnlockObjectSystem(); } I'd prefer something like { LockObjectSystem(); UpdateALLDialogsAndSettings(); UnlockObjectSystem(); } 'cause in this case the people creating plugins wouldn't need to know about all the locking-stuff, and more important - they wouldn't be able to send my app down in flames by simply forgetting to lock/unlock.
Why can't you collect the info they enter in the plugin and then apply it when the plugin finishes. This puts you in total control and you can handle any locking required. Can't say I comprehend precisely what you are getting at with locking, but I assume you only want one user/thread/plugin to be able to change objects at a time. Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
-
Why can't you collect the info they enter in the plugin and then apply it when the plugin finishes. This puts you in total control and you can handle any locking required. Can't say I comprehend precisely what you are getting at with locking, but I assume you only want one user/thread/plugin to be able to change objects at a time. Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
A message-based system like you propose has crossed my mind (and I even started implementing it), but it seems like an overly complex solution to a very simple problem :( Then I'd have create a message-system that handles a lot of different (custom) messages, lock/unlock a message-queue etc.... If only there was a way to 1st) update the UI and thus the gfx-object parameter changes 2nd) render the frame where the rendering would be virtually uninterrupted, and the UI would be allowed to have some lag... The plugins don't "finish" by the way; it's a normal app with an edit-window for the configuration of the selected effect (selected from a listcontrol in another window). So the render-thread is rendering non-stop, and meanwhile the user can change effect-properties in the UI. (Think of a winamp-plugin with a realtime edit-window) Still, right now I'm thinking of going back to the multithreaded system.. But then I still want to find a way to make sure the plugins can't crash the app. Which means taking the locking/unlocking out of their hands - but I still have to find an elegant way to do that :-/
-
Why can't you collect the info they enter in the plugin and then apply it when the plugin finishes. This puts you in total control and you can handle any locking required. Can't say I comprehend precisely what you are getting at with locking, but I assume you only want one user/thread/plugin to be able to change objects at a time. Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
Forgot to mention this : The (plugin)edit-dialog also has to display the current values for all the effect-parameters. Which would mean for a message-based system like you proposed (gathering all entered data and processign it later), that the message-system has to be bidirectional. (Since you're not only inputting new values, but also *reading* them from the object) And that's a whole different, (imho way *too*) complex ballgame. :-( Ps. I don't want to disrespect you or anything, (I really value your input on my problem !!) but your signature looks really "Hey! look at me! I'm a professional developer!" flashy kind of thing :) Isn't it a bit too much..? ;-)
-
Forgot to mention this : The (plugin)edit-dialog also has to display the current values for all the effect-parameters. Which would mean for a message-based system like you proposed (gathering all entered data and processign it later), that the message-system has to be bidirectional. (Since you're not only inputting new values, but also *reading* them from the object) And that's a whole different, (imho way *too*) complex ballgame. :-( Ps. I don't want to disrespect you or anything, (I really value your input on my problem !!) but your signature looks really "Hey! look at me! I'm a professional developer!" flashy kind of thing :) Isn't it a bit too much..? ;-)
Is it feasible to have two instances of the "object system". One is used by the renderer and the other by the UI components. Whenever the renderer has finished etc. it asks the UI object if it has changed, and if so it copies whatever it has to, to get in sync. A lock would only be necessary during this sync process. re. my signature, you should have seen it a year or so back. ;) I'm open to suggestions to tone it down further? Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
-
Is it feasible to have two instances of the "object system". One is used by the renderer and the other by the UI components. Whenever the renderer has finished etc. it asks the UI object if it has changed, and if so it copies whatever it has to, to get in sync. A lock would only be necessary during this sync process. re. my signature, you should have seen it a year or so back. ;) I'm open to suggestions to tone it down further? Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
Neville Franks wrote: I'm open to suggestions to tone it down further? I don't have a problem with it at all :)
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Neville Franks wrote: I'm open to suggestions to tone it down further? I don't have a problem with it at all :)
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Ryan Binns wrote: I don't have a problem with it at all Thanks, I thought it was reasonably tame. Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com