| Forum Index > BW General |
|
LG)Sabbath
Argentina3024 Posts
We’re standing up the PTR again and asking for your help to test some big changes coming down the pipe. Here’s the TLDR: we’re changing how graphics work in SCR. Please test on the PTR to make sure your video card doesn’t run into any problems. https://us.forums.blizzard.com/en/starcraft/t/return-of-the-ptr/1434 | ||
|
onlystar
United States971 Posts
guys please sign up i dont want another debacle where the launcher just freezes every time and game freeze or crash like we had in the past with that google chrome like blizzard app launcher patch that Fd everyone over | ||
|
KameZerg
Sweden1767 Posts
| ||
|
outscar
2832 Posts
| ||
|
castleeMg
Canada786 Posts
https://imgur.com/a/4QmzwqW https://imgur.com/a/CMbf0aX | ||
|
blabber
United States4448 Posts
| ||
|
tec27
United States3702 Posts
On May 16 2020 04:50 outscar wrote: Lol, we've been waiting for months with no answer, and they make it look like they're going to make massive changes, but instead it's just them trying to make sure game supports some browser shit (probably has to do with in-game login/password screen). And they're pushing it because deadline is over because of their incomptency and now they're obliged and forced to do it. Blah blah blah. Don't care. If you break it fully we're all going back to 1.16.1. CEF is used for the majority of UIs in the game (all the menu stuff, bnet, and also for the ingame observer UI). It's an embedded version of Chrome, so it is indeed pretty bad for them to be shipping significantly outdated versions of it, given how many potential known security vulnerabilities it can contain. The fact that it's taken them this long to fix the "CEF spawns 5+ memory-hungry processes for every single piece of UI on the screen" problem is pretty perplexing though. What is even more perplexing is that they've seemingly spent the last few months writing a brand new rendering backend for Windows users (who was asking for that or even complaining about performance outside of the CEF bug and other things that have nothing to do with the rendering technology?), and even more perplexing is that they wrote one for macOS too. They probably spent more hours working on that than they have mac users. On May 16 2020 05:00 blabber wrote: from the message it seems like they need to do it for compliance reasons. I'm guessing the older technologies are no longer supported. hopefully we can do our part and help test the changes and make sure it works so it goes smoothly. The "compliance reasons" part is specifically about CEF (the thing they had to roll back before), it does not apply to the new rendering stack. I don't know why they combined those two pieces so closely (or maybe the community person just didn't understand what the devs told them). | ||
|
TelecoM
United States10700 Posts
| ||
|
tec27
United States3702 Posts
On May 16 2020 08:09 GGzerG wrote: I noticed this yesterday as well and they had some patch but it didn't display any notes. I am hoping this fixes the FPS drops at certain points in games and that is why they mentioned the Graphics cards. Notes for yesterday's patch are here: https://us.forums.blizzard.com/en/starcraft/t/maintenance-patch-notes-may-12th-2020/1427/19 | ||
|
srj
Canada134 Posts
On May 16 2020 05:14 tec27 wrote: CEF is used for the majority of UIs in the game (all the menu stuff, bnet, and also for the ingame observer UI). It's an embedded version of Chrome, so it is indeed pretty bad for them to be shipping significantly outdated versions of it, given how many potential known security vulnerabilities it can contain. The fact that it's taken them this long to fix the "CEF spawns 5+ memory-hungry processes for every single piece of UI on the screen" problem is pretty perplexing though. What is even more perplexing is that they've seemingly spent the last few months writing a brand new rendering backend for Windows users (who was asking for that or even complaining about performance outside of the CEF bug and other things that have nothing to do with the rendering technology?), and even more perplexing is that they wrote one for macOS too. They probably spent more hours working on that than they have mac users. The "compliance reasons" part is specifically about CEF (the thing they had to roll back before), it does not apply to the new rendering stack. I don't know why they combined those two pieces so closely (or maybe the community person just didn't understand what the devs told them). The macOS one makes sense. DirectX isn't available there and OpenGL is being deprecated. They needed to rewrite the backend in Metal. | ||
|
Lorch
Germany3691 Posts
As for the render backend: Why not go for vulkan if you're gonna rewrite it in metal anyway? Available on any OS so you can throw directX out of the window as well. Either way I'd rather have them invest their time into fixing bugs + improving their anti-cheat tbh. Or hell atleast bring OG graphics up to par with a 1.16 client. Though I guess if you are shipping with an outdated version and using a depreciated API like openGL, you really have no choice. | ||
|
tec27
United States3702 Posts
On May 16 2020 10:27 Lorch wrote: I wish they would rewrite the UI and do it in-engine like people used to. I have played many games with these HTML/Chrome menus and it's always laggy and awful. As for the render backend: Why not go for vulkan if you're gonna rewrite it in metal anyway? Available on any OS so you can throw directX out of the window as well. Either way I'd rather have them invest their time into fixing bugs + improving their anti-cheat tbh. Or hell atleast bring OG graphics up to par with a 1.16 client. Though I guess if you are shipping with an outdated version and using a depreciated API like openGL, you really have no choice. I very much imagine that all of the cards that need the DX9 renderer currently also don't support Vulkan (or have showstopping bugs with it). I don't get how moving to DX11/DX12 really removes the need for a DX9 renderer though, given that there are a number of cards they claim to support that are DX10.1 or below. Perhaps they're just stealthily trying to cut support for those cards again and going to see how many people complain? As far as the original graphics go, they mostly look terrible at this point because they decided to compress all of them like they did with HD graphics. The savings for SD-sized sprites end up being quite minimal (especially compared to how much memory they use up through other bad decisions), but the loss in fidelity is quite immense. Fortunately they still ship the original sprites in the game data (likely because SCMDraft doesn't support the compressed versions), so someone could feasibly write a renderer that used them and actually looked decent given enough time. I definitely don't think there's any reason a browser-based UI *has* to be non-performant, and a number of games do it well. SCR's, however, has a lot of really questionable decisions. Every little piece of their UI is loaded up in an isolated frame, every page has a separate HTML file (that all follow the exact same, very simple template), every piece has its own isolated javascript file that has been compiled for very, very old browsers and thus includes a ton of code to implement stuff the game's browser obviously supports. Every javascript file bundles all of its own dependencies (the vast majority of which are common between every piece, but have to be parsed and executed without any shared caching because of this setup). The pieces communicate between each other and the game using a WebSocket, but the protocol used is often incredibly chatty and wasteful. For instance, the Observer UI sends an update for every mineral count change containing the player's name and all of their resource state (that is, if a player spends 50 minerals from 100 minerals, an update is sent not just for 100 minerals and then 50 minerals, but every step of the animation along the way: 100 -> 97 -> 94 -> 91 -> ... -> 50). Each of those state updates then re-renders the entire UI, and mostly happens far faster than the game can actually render a frame in general. Yeah, you can get away with these kind of things when all the communication is happening locally, but god that has to be eating up so many resources and making things perform so much worse. But instead of fixing this kind of low hanging fruit, they're rewriting the whole rendering backend? Truly baffling. | ||
|
TelecoM
United States10700 Posts
| ||
HaN-
France1920 Posts
we’re changing how graphics work in SCR. Do you think it can mean improvement for SD graphics? | ||
|
fazek42
Hungary438 Posts
| ||
|
Bakuryu
Germany1065 Posts
| ||
|
fazek42
Hungary438 Posts
| ||
|
LG)Sabbath
Argentina3024 Posts
| ||
|
TelecoM
United States10700 Posts
On May 17 2020 09:32 LG)Sabbath wrote: I've just spent a full 5 minutes opening/closing my match list to try to get it to pop up, so it's really impressive that they only now found out about UI issues, and tbh I would also just scrap the entire thing and do it over given how bad it's working, hopefully the next iteration won't be as bad, but right now it works pretty much like beta software How could they just find out about it ? Do they not play the game? lol >_< | ||
|
dM-White
Chile341 Posts
On May 16 2020 21:49 Bakuryu wrote: can we just get tec27 to get hired by blizzard to work on SCR? this would be a win-win situation for everybody. THIS ^, the guy seems to know a lot hahahaha | ||
|
A.Alm
Sweden534 Posts
| ||
|
Poegim
Poland266 Posts
On May 16 2020 21:49 Bakuryu wrote: can we just get tec27 to get hired by blizzard to work on SCR? this would be a win-win situation for everybody. You have my sword. | ||
|
TelecoM
United States10700 Posts
| ||
|
SchAmToo
United States1141 Posts
On May 16 2020 05:14 tec27 wrote: What is even more perplexing is that they've seemingly spent the last few months writing a brand new rendering backend for Windows users (who was asking for that or even complaining about performance outside of the CEF bug and other things that have nothing to do with the rendering technology?), and even more perplexing is that they wrote one for macOS too. . Mmmmm Windows performance on non-game screens is pretty bad. I've noticed memory hogging and a ton of bugs on Windows. | ||
|
tec27
United States3702 Posts
On May 19 2020 07:23 SchAmToo wrote: Mmmmm Windows performance on non-game screens is pretty bad. I've noticed memory hogging and a ton of bugs on Windows. Thing is, switching to a new rendering backend isn't going to change that at all. It may even make it worse, given that they seem to devote a lot less energy to actually ensuring things work before they push them out to everyone at this point. All the non-game UIs (and the in-game observer UI) are handled via CEF. CEF is an embeddable version of Chromium, which renders via Skia. In a "real" browser, or when CEF is managing an actual window, Skia supports hardware acceleration (e.g. using DirectX or OpenGL to render graphics with your graphics card, rather than software implementations), but CEF does not support hardware acceleration when rendering in "offscreen mode", which is how SC:R uses it. Thus, all CEF is doing here is rendering out to an image via your CPU, telling SC:R what pixels have changed, and letting SC:R deal with putting those pixels on the screen. This isn't a hard operation for a graphics card to do, and there's really nothing complex about the code they'd have to do it, regardless of graphics API. There's no real room for further optimization by choosing a different rendering API, as the bottleneck is not there. Very likely, memory problems and bugs you are seeing are due to things that they aren't working on at all here: wasteful allocations and initialization of things that aren't needed, not following or paying attention to best practices when it comes to developing web UIs, inefficient communication between UIs, spinning up far more expensive background processes than is actually needed, etc. This is like painting your car a different color because you see it's been getting bad fuel efficiency. | ||
|
MeSaber
Sweden1235 Posts
| ||
|
TelecoM
United States10700 Posts
Grant Davies @ forums 15m This is live now. Have a great weekend! | ||
|
LML
Germany1781 Posts
On May 22 2020 06:43 GGzerG wrote: Apparently the PTR is live, but I don't see the option to join it. Blue post on StarCraft.com forums 15min ago. Grant Davies @ forums 15m This is live now. Have a great weekend! ![[image loading]](https://i.imgur.com/ImSNiRb.png) | ||
|
TelecoM
United States10700 Posts
| ||
|
tec27
United States3702 Posts
| ||
|
TelecoM
United States10700 Posts
| ||
|
TelecoM
United States10700 Posts
| ||
|
QuadroX
386 Posts
On May 22 2020 08:11 tec27 wrote: The version of CEF is still unchanged, which seems absurd since this was they thing they've been trying to roll forward for months now. Seems like an important piece to test as well, given how many problems it caused before. How do you know? I noticed huge performance boost on PTR, menus are ligheting fast and now SC:R supports my Intel HD Graphics 620 which was a pixelated mess before the update. | ||
|
TelecoM
United States10700 Posts
On May 23 2020 01:58 QuadroX wrote: How do you know? I noticed huge performance boost on PTR, menus are ligheting fast and now SC:R supports my Intel HD Graphics 620 which was a pixelated mess before the update. Yea, it is working amazingly well. I can't wait for them to push this through, can finally stream again, and don't have to buy a new computer it seems! | ||
|
LG)Sabbath
Argentina3024 Posts
| ||
|
tec27
United States3702 Posts
On May 23 2020 01:58 QuadroX wrote: How do you know? I noticed huge performance boost on PTR, menus are ligheting fast and now SC:R supports my Intel HD Graphics 620 which was a pixelated mess before the update. You can compare the versions of libcef.dll in the PTR and non-PTR versions and see they are they same: ![[image loading]](https://i.imgur.com/2qRpzz3.png) Thus, this update still hasn't been rolled forward. I had never actually gone and looked up what Chrome version that corresponds to, but apparently it's from April 2015, which... oof. | ||
|
QuadroX
386 Posts
| ||
|
tec27
United States3702 Posts
The patch doesn't seem to contain many other changes from further inspection. The UI scripts look to be the same other than a few things renamed here and there, nothing functionally different as far as I can see. | ||
|
fazek42
Hungary438 Posts
I imagine that's because the display is 60 Hz -- however, and I'm not sure if this is placebo or not, but now both modes feel (equally) a little choppy, whereas SD at 200 FPS seemed to be smoother previously (and HD unplayable). SD graphics is still looking terrible, so no improvements there. | ||
|
tec27
United States3702 Posts
On May 24 2020 02:44 fazek42 wrote: On a macbook pro late 2015 model, with Catalina, FPS in HD is increased to 60 FPS (which is great! I think I used get around 39 FPS), but SD is now also capped at 60 FPS. I imagine that's because the display is 60 Hz -- however, and I'm not sure if this is placebo or not, but now both modes feel (equally) a little choppy, whereas SD at 200 FPS seemed to be smoother previously (and HD unplayable). SD graphics is still looking terrible, so no improvements there. Is vsync on perhaps? Or maybe enforced by your graphics driver for directx or something? The settings don't save/share between PTR/non-PTR so that may just be something you have set differently between the two (although I don't think vsync defaults to on so who knows, really) | ||
|
srj
Canada134 Posts
| ||
|
fazek42
Hungary438 Posts
On May 24 2020 08:09 tec27 wrote: Is vsync on perhaps? Or maybe enforced by your graphics driver for directx or something? The settings don't save/share between PTR/non-PTR so that may just be something you have set differently between the two (although I don't think vsync defaults to on so who knows, really) Yeah, V-sync was off. Turning it off or on made no difference. I found, however, that going to windowed, and then back to windowed-fullscreen made the FPS go up... It reached a 100 in HD and 150 in SD! Damn, lol :D Should probably test on windows 10, but there's not enough space on my bootcamp partition to install PTR I think... edit: After resizing partitions and testing on Windows 10, I can say that it's a similar experience under Windows 10 as well. Except the window hack doesn't work here, and I get a capped 60 FPS both in HD and SD, whereas with the regular version I get a 100 FPS in HD and 150 in SD. If I go to windowed mode, I get 200 and 300 FPS respectively. I'll post on the official forum as well and hope that by the time they roll this update out for real it'll support intel integrated graphics properly as well... | ||
|
Master of DalK
Canada1803 Posts
On May 23 2020 03:03 tec27 wrote: You can compare the versions of libcef.dll in the PTR and non-PTR versions and see they are they same: Thus, this update still hasn't been rolled forward. I had never actually gone and looked up what Chrome version that corresponds to, but apparently it's from April 2015, which... oof. How is their version of CEF that old??? What a joke. | ||
| ||
|
|
WardiTV Team League
OSC
Replay Cast
KCM Race Survival
WardiTV Team League
Korean StarCraft League
RSL Revival
Maru vs Zoun
Cure vs ByuN
uThermal 2v2 Circuit
BSL
RSL Revival
herO vs MaxPax
Rogue vs TriGGeR
[ Show More ] |
|
|
EPT
