scene view refreshes much slower than 144Hz

Unity Engine
,
1

navigating in the scene view looks sluggish, definitely not 144Hz, even maximized.
the game view plays at 144hz
bug# 1207034

2

My game in Unity4 PFS:500+
when i upgrade Unity5.x 160+
in Unity2017 120+
when I upgrade Unity2019 it never over 80+
so you want 144hz? you must be fucking kidding me

is the same game ,the same project, the same code
you just upgrade Unity

3

I feel like you’re using OP’s problem as an excuse to complain about your unrelated problem. If your game’s performance gets so bad without changing anything then open a bug report, add some profiler dumps and create a post about it like OP did.

4

I report more then 30+ bug’s emails to unity QA team, all of then were be closed, because they just tell me
“We can’t reproduce it, so the problem will be closed, thank you”

this is why i using OP’s problem now

i think you don’t know i upgrade Unity2019.3f3 today
now i just press ctrl+s want to save the scene, the unity 100% crash
yesterday i just save sucessful in Unity2019.3f2
today i just only upgrade f3, i even can’t save the scene, can you believe?

so now i don’t want send any fucking email to QA, Because I don’t think it makes any sense

5

I mentioned this in my previous comment: make a new post and add profiler dumps. Those dumps are all you need to prove the performance problem is real.

1 Like
6

Unity QA were able to pretty much reproduce every bug I submitted so far. In order to achieve this, it takes an enormous amount of preparation on my side for the bug-report. However, if the issue is important to me, I have to invest that time.

Here are some tips that helped me to achieve a high “We’re able to reproduce the bug” rate from QA. Before I submit a bug-report, I ask myself:

  • Is this the type of bug-report I would like to get too?

  • Written politely and respectful. It’s a human person who is going to read my bug-report and most likely not the reason of that bug.

  • The problem is clear communicated, either through text or video, perhaps both.

  • The report is factual.

  • Would this bug-report help me to fix the problem?

  • It contains information how I can reproduce the error.

  • It contains the files required to reproduce the error.

  • It contains any data that is related to the issue, for example a crash.dmp file.

  • The report should read as simple as possible. The harder it’s to understand the problem, the higher the chance QA gives up early to reproduce the issue.

If I can’t answer both of these questions with a “yes”, then it’s not worth submitting the report yet.

The best report in my opinion is one where they can just follow a step-by-step list how to reproduce the problem, along with a video how I do that step-by-step repro list. The video is to prove the error really exists, it’s harder to deny there is an error, if you have proof.

It takes time to create these kind of reports, but as I mentioned earlier, QA’s repro-rate is really good then. Now they just need to fix those issues they have in their bug-tracking system :wink:

3 Likes
7

a screen running at 144hz is not the same as fps… You can still have a graphics output of 1fps and run at 144hz…

8

MS is a linear measurement.