separate process (not thread) dedicated to display?

[til]

I've got this idea, but I don't know if it is crazy:  

I'd like to try having my application spawn a separate process that runs a simple sfml display window.  The main process (MP) will compose and render graphics frame by frame, but then copy each frame to the display process (DP).  I think there would be cool user interface advantages, but will the cost of transferring full graphics frames between processes be too limiting in general?

The advantage would be that if the MP got stuck (waiting for hardware, crash, etc) the user interface could remain responsive.  If the DP doesn't get new frames to display, then it will slowly fade to black and spawn another temporary minimal MP to help manage the situation.  Just a simplified query engine to put up a few options like restarting, waiting, send angry emails, etc.  This would also allow cool interface separation from multiple tasks or GUI views, etc.

Is it crazy to try and pass full graphics frames between processes fast enough?  Is it close enough to depend on the resolution/color-depth of those frames?  Is this commonly done already and I just don't know it?

[Spellbreaker]

I don't know if I get your Idea correctly, but everything you mentioned is possible by using threads.

Using Exception handling and other stuff you can nearly catch every crash/freeze/hang whatever, so it wouldn't be a problem to display some kind of dialogue afterwards.

I also don't think how smart windows is, if processes directly share memory or pass data, I'd also guess some anti-vir-guards will make an alert if you try to read memory that has been written by another process ( if that is even possible, what I don't know ).

I wouldn't put too much effort into that Idea. It is so much work, just to handle an event that should never happen

Greets,

Spellbreaker

[til]

Thanks Spellbreaker, normally I would agree with you.  I also think exceptions + threads will provide 99% of what I need.  I should have mentioned that the goal of this app is specifically to cover more cases, and be as robust as possible -even at the sacrifice of speed.

Many programmers still don't realize how difficult it can be to overcome a system call that is stuck in hardware.  (i.e. slow network, scratchy optical media, or even the graphics adapter when users change displays or settings, etc.)

In the end, I think you are right that it will depend more on the interprocess communication mechanisms supported by the OS.  I guess you are helping me realize I am talking to the wrong forum.  I need to pick an IPC toolkit/api, run some speed trials, and then work with it's own forums if it fails.

I think it is already clear that sfml will work well once I'm ready for it.