[haiku-development] Re: Re : Virtual CompositeEngine

  • From: looncraz <looncraz@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 02 Mar 2013 22:33:58 -0800

First, thank y'all for testing and providing feedback!

On 3/2/2013 14:38, Przemysław Pintal wrote:
[results]
I have a problem with this benchmark. Do not set the resolution that I want.

The resolution code is about as simple as can be, I can't imagine the resolution being wrong - however, the window size and shape are calculated based on available screen area and the buffer is stretched/shrunk to fit.

And there is a glitch in Terminal when I close the window with
animation. [Example]
See my response (below) to Justin Stressman...

On 3/2/2013 15:28, Justin Stressman wrote:
I was curious about this as well. The last line of the terminal output is overwritten by the next command prompt, so you lose part of the output when it's done running. Also, do you (looncraz) need that information? The tasks per thread etc?

I only need that information if things are messing up or memory leaks, otherwise no. Also, the information being erased it the live status of the frame rate - I didn't notice that it corrupted the command line simply because my path line is too long.

I think the benchmark should check the rendering time of frames!
Because you can have many frames, but the lag will occur. I've read a
bit about it lately.
The benchmark, internally, tracks 256 frame times and performs a weak statistical analysis to determine the current and average frame rate (the rate needs to "warm up" as a result). This information, currently, is only useful for detecting late frames when the system is fast enough to hit the rate limit. This is simply because the rendering load is static, each pixel and each frame have the exact same computational cost give or take the slight difference due to rendering the fps counter. Late frame detection is not enabled in the build I posted as the frame rate can stay rock solid at a given rate when the system can handle the load - late frames are not occurring because the control thread wakes up early, does its prep work, then spins for the next retrace(VSync).

Single core systems will be hammered by this benchmark, but less so than would be expected from such a highly threaded work-load thanks to not having any locking during the frame rendering.

Thanks for the feedback!

--The loon

Other related posts: