Chromium Embedded Framework is very easy to implement and it would add SO much power to BYOND. It would also mean strict compatability against all other byond clients, no longer relying on someone having a specific IE version and have a nice following of web standards(which ie clearly fails at).
This is a rather daunting request so I'd expect it to be implemented over time, if done. It would also open the doors to a linux port as I can imagine this is the main issue against a Linux port of the client.
One could also have a browser atom for a web based gui or something(transparency)
note: I do know this was requested a year or so ago, but with IE being the major stopping point of progress it was worth another look
ID:1877855
 Jun 19 2015, 8:44 pm
|
|||||||
Resolved
| |||||||
CEF in particular had trouble because Chrome really wants to use a multi-process approach, and CEF is downright crashy in single-process mode. I set CEF aside in hopes that a fix would come along, but there still appears to be no solution for that in sight.
| |
Awesomium is an expensive version of CEF and has terrible compatability with other OSes and poor compatability with Windows, the upside being its slightly easier to implement.
Despite being multiprocess(thats really not a big deal), you can still use it singlethreaded. | |
As stated, it crashes a ton in single-thread mode, the framework simply wasn't designed with single-threaded programs in mind.
| |
You don't have to move from being single-threaded and even if you multithread just the web portion it really wouldn't be that big of a deal.
| |
You obviously don't understand the amount of work it takes to just 'multithread' something.
| |
Considering it wouldn't be the entirety of byond that would be multithreaded(which is optional by the way, as i've said three times), yes it wouldn't take much work.
| |
If it wouldn't take much work Lummox would have considered that to be a solution already, they've tried threading off the map updates and various other aspects of the language and it went very poorly. I'd imagine it's a lot less trivial than you're making it out to be.
| |
Hrm, is Awesomium actually tied to CEF or is it just similar? If it can handle single-process then it's a possibility. CEF definitely had trouble with single-process and appears to still have issues to this day.
Hoo boy though, the attempt to get CEF working was not easy. I did get to the point (at the time) where it could launch a browser window for the map in Runt. | |
Awesomium is basically CEF but with a slightly higher-level api but is often out of date. CEF has been catching up and is the open-source alternative(also without the massive licensing requirements).
What exactly is the issue with having multiprocess? Are you confusing multiprocess for multithreading? | |
Are you confusing multiprocess for multithreading? Oh... Yup... That was me. | |
Somepotato wrote:
What exactly is the issue with having multiprocess? Are you confusing multiprocess for multithreading? Multiprocess is worse than multithreading because it complicates everything. I'm still not even sure how multiprocess could be made to work. CEF's docs were not particularly enlightening, but my general understanding is either the process has to be forked or a new process is started by basically passing info via the command line but running the EXE all over again. The latter appeared to be the case as far as I could tell, and that won't ever fly with Dream Seeker. | |
You don't have to run under the same EXE, and you pass it the commandline args and it returns true/false IIRC whether or not its a CEF process. Everything is hidden behind the API, you don't have to worry about the fact its multiprocess at all. Also yeah thats one of the main things in CEF vs Awesomium is the documentation is much better for Awesomium.
| |
I'm not sure how I could make it run under a different exe without actually adding on another project. (I guess that's doable, but... ugh.) But it annoys me a lot that single-process is so frickin' buggy.
| |
Separate process is vital to avoid killing/locking up DS if for some reason CEF crashes or lags out.(looking at you, internet explorer). The separate executable isn't that much of a pain in terms of maintainence for the glorious outcome that comes with it(you can define javascript functions and all that with massive performance boosts, for starters)
| |
This would open up so many doors it's insane. Actual proper handling of CSS (instead of the choice between: BYOND implemented CSS handling like in OUTPUT controls which is incredibly lacking, and IE, which as mentioned comes in a variety of flavors and is pretty shit for CSS ~anyway~).
Transparent browser windows would basically allow for no-shit proper modern UI across the board. While I am hesitant to knock the old-school windows panels and so on, they are rather windows 98 and don't offer much in the way of aesthetic customization. Simply put, this should absolutely and unequivocally be high priority to implement and if you need to consult with Somepotato here, who obviously actually knows what he's talking about, then hey maybe do it. | |
This is all basically made moot by the web-client, where priority focus is shifted at the moment. At some point it would be ideal to drop existing Dream Seeker entirely in favor of a web-client implementation as it provides a ton more in the way of options for interface than Dream Seeker ever will.
This obviously means it'll be running in whatever browser the client chooses and that'll determine the level of HTML/CSS/Javascript support that client gains the benefit of. | |
In addition to the incapability of the webclient to do useful native things without an extension, the performance is noticeably worse for larger projects and everyone will most certainly not switch to it.
The webclient is nice for smaller projects, but using that as an excuse not to add features to DS is rather far fetched. | |
The webclient is always undergoing optimizations and is currently in the process of being heavily revised to bring it up to par with Dream Seeker in terms of functionality and speed.
Not sure what you're talking about with extensions, the web-client works fine natively on any browser with proper HTML5 support. Works fantastic on Chrome, I've seen it run fairly well for SS13 on all three major browsers. Eventually, switching to it will provide much greater benefit than not switching to it. Lummox focusing a ton of effort into implementing CEF is simply not ideal at the current time, and may not be in the future once the web-client is further fleshed out. | |
Login to reply.
Overall, I agree though. Awesomium and OpenGL via GLFW3 could move DS off of GDI/DirectX and open the door to non-windows DS clients that actually work.